Manual install of Aptible CLI breaks cross-team dependency management

[davidgoli]

Our team previously depended on a Gemfile and the aptible-cli gem to ensure all our teammates were running the same version of the Aptible CLI. With the recent push to have people download the Aptible toolbelt directly, we no longer have the ability to ensure all our developers are running the same Aptible CLI version. Perhaps Rubygems/Bundler is no longer the appropriate solution for the Aptible CLI, but it's a real disappointment that there isn't a lockable way to ensure version conformity within a client repository. Is there anything like this in the works? Downloading the toolbelt manually seems like a short-term stopgap on the way to a different dependency management tool.

[davidgoli]

FYI we'd gladly use Docker for this, except Docker for Mac is unusably slow at this stage for non-trivial applications. Docker is not currently a workable solution.

[krallin]

Hi there, thanks for reaching out.

With the recent push to have people download the Aptible toolbelt directly, we no longer have the ability to ensure all our developers are running the same Aptible CLI version.

We do still provide versioned downloads of the Aptible Toolbelt, so if you'd like, you should in fact be able to ensure everyone uses the same version of the CLI by downloading it from the versioned URLs.

You can find a listing of all v0.8.4 URLs here: https://github.com/aptible/www.aptible.com/blob/fee5324f5d50b3b42083689caa1beb99f615bb24/data/toolbelt.yml

This file will be updated when new versions come out, and you can also find historical versions there: https://github.com/aptible/www.aptible.com/commits/master/data/toolbelt.yml

it's a real disappointment that there isn't a lockable way to ensure version conformity within a client repository. Is there anything like this in the works? Downloading the toolbelt manually seems like a short-term stopgap on the way to a different dependency management tool.

I don't understand what you mean by "version conformity within a client repository" — can you clarify what you meant here?

[davidgoli]

By "client repository" I mean a repository that depends on Aptible CLI, such as my team's. By "version conformity" I mean we'd like to enforce that all of our developers are guaranteed to use the exact same version of each of our dependencies. This is currently guaranteed in most of our dependencies by a yarn.lock, npm-shrinkwrap.json, Gemfile.lock, or language-dependent dotfiles like .nvmrc, .ruby-version from nvm & rvm, respectively.

A manual process of instructing every developer to manually visit a webpage and download a version of a package is error-prone and not an acceptable substitute IMO. We could write scripts in our repository essentially recreating a package manager by detecting the installed version of the Aptible toolbelt & forcing an upgrade if the dev's machine is behind, but that creates extra work unnecessarily when there are plenty of great package managers around already.

[fancyremarker]

Hi @davidgoli ,

We stopped using RubyGems as the default package manager for the Aptible Toolbelt when we introduced non-Ruby dependencies. (The most important such dependency is OpenSSH >= 6.7, a version newer than what ships on many OSes used by our customers, including OS X <= 10.10 and Ubuntu <= 14.04. The specific OpenSSH version, in turn, is required for the security and auditing features of our latest Aptible SSH Portal.) I agree with you Bundler is an excellent way to manage dependency versions; it's just no longer appropriate for us given our non-Ruby dependencies.

Based on your current use case, I think the best option may be to continue installing aptible-cli via Bundler. You'll also need to ensure that your team has OpenSSH >= 6.7, but you should be able to do this using an OS package manager like Homebrew, APT, etc. You may also want to quiet the warnings from aptible-cli when you do this; more on how to do that in the source.

Other potential options (less apt for your specific goals, I believe) include:

• Installing Aptible Toolbelt via an OS package manager. On OS X, you can brew cask install aptible. This achieves package manager standardization but not version management (at least not automatically); that said, for the example of Homebrew, you can technically install a specific version, e.g.:

    https://raw.githubusercontent.com/caskroom/homebrew-cask/05d9891/Casks/aptible.rb
  

• Installing from the URLs on our Toolbelt page. You'll notice that all the download URLs reference a specific version of the Aptible Toolbelt. So if you target a specific URL in your system configuration scripts, you will indeed ensure that everyone on your team runs the same version. This achieves version management but not package manager standardization. In other words, you'd have to choose or design a package management solution other than Bundler/NPM/Yarn.

[davidgoli]

Thanks for the detailed response. If I may elaborate: our team includes developers on both Mac and Linux machines (and possibly Windows in the future), so an OS-dependent strategy won't really work for us.

I assume you've tried adding these dependencies via Ruby gem native extensions, and that isn't feasible? Many widely-used gems support non-Ruby dependencies (eg rmagick)