Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Provide a more isolated installation mechanism #13

Open
velovix opened this issue Oct 23, 2020 · 0 comments
Open

Provide a more isolated installation mechanism #13

velovix opened this issue Oct 23, 2020 · 0 comments

Comments

@velovix
Copy link
Member

velovix commented Oct 23, 2020 •
edited
Loading

Using Pip for installation is a reasonable solution, but there may be better options. Using Pip requires that Python dependencies are installed globally, which may conflict with other tools. Arch Linux in particular saves globally installed Pip libraries to /usr/lib, which means they can conflict with Python packages installed with Pacman.

Here are some other options, with a non-exhaustive list of pros and cons:

pipx

Pros:

  • A very lightweight solution
  • Allows us to still distribute with PyPI
  • Easy updates

Cons:

  • It's another tool we have to ask users to install
  • Ubuntu doesn't have PATH set up properly by default to allow pipx to work out of the box
  • The user has to set up their PATH in such a way that the command is accessible both with and without sudo

AppImage

Pros:

  • Offers a one-liner installation experience (sudo curl https://aotu.ai/brainframe.AppImage > /usr/local/bin/brainframe && sudo chmod +x /usr/local/bin/brainframe)

Cons:

  • No automated update experience. Users would have to keep downloading new releases.
  • Apparently non-trivial to use with Python

PyInstaller

See #27

Pros:

  • One-liner installation experience, like AppImage
  • Easy to use

Cons:

  • No automated update experience, like AppImage
  • Lagging support for Python releases

Snap or Flatpak

Pros:

  • Offers a one-liner installation experience for some distributions
  • Automatic updates
  • Easy to use

Cons:

  • May defeat the security goals of these tools. The CLI needs pretty significant access to the system.
  • Some distributions don't have either available by default. Users may be reluctant to install an entire daemon just to install one tool.
  • Snaps can only really interact with Docker if Docker itself is installed with Snap.

Distribution Packages

See #25

Pros:

  • A very lightweight solution from a user perspective
  • Some users may find this more palatable than other options
  • Easy updates
  • dh-virtualenv allows us to package Python dependencies independently from the package manager

Cons:

  • Supporting multiple distributions is an O(n) problem, with each distribution having its own packaging system and versions of our dependencies
  • Installation effort depends on the distribution, but will rarely be a strictly one-line affair unless we manage to get the package into the official repositories
This was referenced May 4, 2021
Merged
Open
velovix added a commit that referenced this issue May 12, 2021
@velovix
Create a deb package (#25)
51d3740 
This adds the necessary configuration and CI to build the CLI as a deb package. This is accomplished using dh-virtualenv, which allows us to package Python dependencies in a virtual environment. Using dh-virtualenv not only allows us to use our own versions of Python dependencies, it also isolates our dependencies from the rest of the system. This allows us to have our own isolated installation of Docker Compose as a dependency, whose version we can update at our own pace.

The deb also obsoletes the need to install curl and rsync for the user, since they can now be expressed as package dependencies. However, Docker is currently still being installed for the user. We could consider using Ubuntu's version of Docker if we're comfortable with supporting an older version.

This includes an overhaul of our configuration system, so that different distributions of the CLI can be distributed with different defaults. Defaults are now provided by a defaults.yaml file. The deb package is given its own custom defaults.yaml that is configured to use system package locations like /var/lib/brainframe instead of user-installed locations like /var/local/brainframe.

Unfortunately, dh-virtualenv requires that we have a setup.py because it runs python3 setup.py install to add the application code to the virtual environment. I've tried to keep the setup.py as minimal as possible, shelling out to Poetry when I can.

This change is, admittedly, not immediately useful on its own. We would need a PPA or our own repository to distribute this deb to users, and updated instructions to go along with it. We will probably want to provide a script similar to get-docker.sh that handles all the installation steps for the user so that we can preserve our single-line installation experience.

See #13, which this PR does not resolve on its own.
@velovix velovix mentioned this issue May 22, 2021
Merged
6 tasks
velovix added a commit that referenced this issue Aug 3, 2021
@velovix
Add a PyInstaller build for unsupported distros (#27)
d7cb483 
This adds configuration to build the CLI as a PyInstaller executable along with the necessary supporting code. The PyInstaller executable would be an option for users of distributions whose package manager we don't have support for.

Since there's no automatic update mechanism available, this also implements a new self-update command that pulls the latest version of the CLI and replaces the current version with that one.

Unfortunately, this version of the CLI does not ship with its own version of Docker Compose. Packaging Compose into PyInstaller isn't straightforward, and it can't be run as a module because the Python interpreter is embedded in the binary. Instead, the expectation is that the user installs Compose with whatever mechanism they prefer.

See #13, which this PR does not fix on its own.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@velovix