Consider having the CLI manage its own Docker Compose executable
velovix opened this issue · comments
Currently, we model Docker Compose as a system dependency that must be installed by the user. On Ubuntu 18.04, we have the option of installing it for the user with Pip. However, as we found with some customers, this leads to a fairly clumsy experience for a few reasons.
- We install Docker Compose with Pip to make it easy for users to upgrade it. However, installing global tools with Pip can undesirably affect other Python applications and is incompatible with some Linux distributions.
- For distributions that are not officially supported, users need to install Docker Compose themselves. They also need to take care to install the version we require, which may not be available on their distribution's package manager.
- Any time we attempt to manage a global application for the user, we run the risk of interfering with other applications that use this tool. This is unavoidable for some applications, but is always a consideration.
I propose that we instead manage a Docker Compose executable outside the user's PATH that we install and upgrade automatically as necessary. We would use the PyInstalled version of Docker Compose for this, since user-facilitated upgrades are no longer a problem. This executable would be in the install path, which is /usr/local/share/brainframe by default. This has the following benefits:
- We can install Docker Compose automatically for all users, not just Ubuntu 18.04 users
- This allows the user to have any version of Docker Compose installed that they want, including their distribution's (maybe very old) version
- The tool can manage installation and upgrades to Docker Compose automatically, so it's transparent to the user
- Since we can now use the PyInstalled version and it's not added to the user's PATH, it can't interfere with other applications
FAQ
Is it weird for one executable to manage another executable like this?
Maybe a bit, but it's not entirely unheard of. GStreamer includes this executable called gst-plugin-scanner that's outside the user's path and run by GStreamer to find plugins on the user's system. It's kind of like using an executable as a library.
@BryceBeagle @apockill I'd be very interested to hear your thoughts on this 👀
Will this make it easier or harder to manager multiple supported versions of linux at once (e.g. Ubuntu 18.04 and Ubuntu 20.04)?
We would use the PyInstalled version of Docker Compose for this
Would we be pulling it from a script or source that manages the downloading the correct binary for us? That might make it easier to support different distributions. Since Pyinstaller seems to be harder to run on many different linux flavors, I'd imagine we'd need something like that.
Would it not be easier to distribute the brainframe-cli using an official package on a PPA (and the AUR 🚀)? That way we don't need to manage the executable (the package manager does that for us) and there's no chance of breaking global packaging configuration.
Will this make it easier or harder to manager multiple supported versions of linux at once (e.g. Ubuntu 18.04 and Ubuntu 20.04)?
Docker Compose already provides very good compatibility with a wide variety of Linux distributions, so it hasn't been an issue when supporting multiple Linux distributions. The problem I want to solve here exists on all Linux distributions: when we deal in global state (in this case whether or not Docker Compose is installed and what version it is) we run the risk of conflicting with other systems on that computer and have to be very careful when messing with it. If we manage our own Docker Compose executable outside the user's PATH, we can upgrade it as we please and it no longer has a risk of affecting other components.
Would it not be easier to distribute the brainframe-cli using an official package on a PPA (and the AUR )? That way we don't need to manage the executable (the package manager does that for us) and there's no chance of breaking global packaging configuration.
This would mean that we're stuck with whatever Docker Compose version the Linux distribution provides us. On Ubuntu, that might be too old to do what we want, and on CentOS it definitely would be. We could ship our own upgraded Docker Compose package in our PPA, but now we're back to managing the executable and it has an effect on all applications on the user's computer that use Docker Compose. Also, now we take on the normal issue of using distribution-specific package management, in that it would be an ongoing O(n) effort for every distribution we want to support.
Will this make it easier or harder to manager multiple supported versions of linux at once (e.g. Ubuntu 18.04 and Ubuntu 20.04)?
Docker Compose already provides very good compatibility with a wide variety of Linux distributions, so it hasn't been an issue when supporting multiple Linux distributions. The problem I want to solve here exists on all Linux distributions: when we deal in global state (in this case whether or not Docker Compose is installed and what version it is) we run the risk of conflicting with other systems on that computer and have to be very careful when messing with it. If we manage our own Docker Compose executable outside the user's PATH, we can upgrade it as we please and it no longer has a risk of affecting other components.
Oh okay. I just assumed that since it's distributing a pyinstaller binary, they would have to distribute different ones for different systems. If it's a one-size-fits all (or most), that's awesome!
Implemented in #25 for deb and PyPI installations, which have Docker Compose as a Python dependency. The PyInstaller version still requires an external Docker Compose binary by design.