How should projects that interact with or depend upon external binaries handle version specific failures?

  softwareengineering

I have encountered this scenario twice recently, in two different projects and languages:

  1. A python project defined an is_interactive() function that used os.isatty() to know whether it could actively accept user input from a terminal. This function worked in all scenarios except specific older versions of Git-bash for windows, where os.isatty() returned a false negative.

  2. A Rust crate with dependencies on https://www.mingw-w64.org specifically invoked mingw binaries to produce an output, but it appears that something has changed with those binaries since the crate was written, and now they require Linux/cygpath style path inputs.

Both of these situations involve interacting with an outside binary (Git bash, mingw utilities) without any sort of version control, and now some change within the binary conditionally breaks interaction with the software.

Writing unit tests to confirm the external binaries are within some version constraints seems like the wrong way to go.

The projects could clearly identify version requirements in a README, but is there a better way to handle this type of scenario?

LEAVE A COMMENT