I have been troubled by the idea that software projects require certain versions of tooling to be usable. It is not that one project requires version X and another requires version Y, it is how we get those versions onto our systems. But also how to give the user the freedom to use whichever version they might like. In this context, the user is a developer and a not project user. Also usable is not the projects delivered application works but the development experiences are usable.

This problem is not only limited to The Developers Problem but also there are so many great applications out there that are not packaged for all operating systems. While binaries can be downloaded and installed by the user for these applications, there is a time complexity associated. This is The Random Application Problem.

The point that the user is the developer is important. For the most part, being able to run different versions of a tool is not the normal use case for a tool but while doing development work the environments may not be constant between projects. I guess if you are only working on one project this would be a nonissue, but how many of us only work on one project?

The projects that I have been working on as part of kuadrant.io all address this problem by using make targets that download the missing tools when you run a make target that requires that tool. These downloads are placed into a local bin directory in the project, then any make target will use those versions. It is super helpful and gets you up and running so fast. 

I do like this approach but it has its issues. The simplest issue is the implementation that Kuadrant uses does not check if the downloaded version is the correct version the next time you run the make target, only that it is there. This has led to some people having issues with PR checks later in the development cycle. The workaround is to remove the bin directory every so often forcing the re-download of the tools. But that is the simplest issue.

The next issue is any scripts that are used within the project need to define the path to the tool that is required before the user can call the script. This ties into make downloading the tool before running the script beforehand, I will talk on this point in a bit. The scripts become more obscured as now it's not the tool that you are calling but some variable in the script. As it is a variable that could be changed as the script progresses, unlikely but possible. There is then the downloading of the tooling for the script. It means the script must be called by a make target that also calls the tooling make targets. While this is not all bad, and it does seem to be much easier to use make targets for calling scripts, it does bring in an extra step. This forced use of make targets hides what is happening in the background.

The downloaded tooling is not in your path, it is in a bin folder in the project. This would mean if you have one of the tools installed in your path, that version most likely does not match the version the project recommends. Now if you want to do something custom that there is currently not a make target for, you run into the issue that the version is wrong. Yes, you could call it directly from the bin folder but this will become a pain once you start moving around directories in the project as paths will change. Of course, you could add that bin folder to your path but that is messy also. Can you be sure it is the bin version and not the local version that is being used? How does this work if you are moving between projects? Or even open multiple terminals?

In the none-developer situation, I have a selection of applications that help my daily computer user experience. The example application I will use here is k9s, it improves interacting with Kubernetes clusters. If you work in Kubernete environments and have not checked it out before, you really should.

There are several ways to install k9s using brew, pacman, choco, and some more. But there is no installation package for dnf on my fedora installation. So I download the binary from GitHub and add it to my path. K9s is nice in that the UI will tell the version you are using and if there is a newer version available. When there is that never version available I have to repeat the process of going to GitHub, grabbing the binary, and adding it to my path. 

While those are not hard and now I have gotten a system in place for quickly doing it, it is still a pain to have to do it. K9s is the best case here, its UI tells you there is a new version available. There are some of these random applications that I use that do not. For me to know when there is a new version of them I need to subscribe to email notifications for the releases. This works but we all know how much we love getting automated emails.

If these applications had an auto updater I also don't think I would like that. The idea that something randomly updates is something that I don't agree with. The user should have control over when to update the applications they use. On the other hand, auto-updates are so much simpler to use.

This is the introduction to the latest problem which I feel can be addressed. While here I have only been looking at The Developers Problem from the point of binary tools that the project uses there is also a large problem of which version of a programming language is used. Looking at golang in this case. Then with The Random Application Problem again it is only the binaries that I am thinking about. TMany great applications require more resources than just a single binary.

Why mention the language or more complex applications? Well, I have slowly been working on a solution to the single binary problem in the background. It is coming along nicely but currently not ready to share more.