search

artsy / README

:wave: - The documentation for being an Artsy Engineer
Creative Commons Attribution 4.0 International
1.1k stars 120 forks source link

RFC: make `asdf` the default version manager #505

Closed pvinis closed 1 year ago

pvinis commented 1 year ago

Proposal

Use asdf as our default version manager. It makes it easy to handle multiple tools and their versions.

Reasoning

Many people at artsy have started using asdf. We have also added it to eigen and energy and it has been great. It would be great to extend the usage to all our repos, so we have more consistency. Some people might still want to use their version manager of choice. That's fine, we can keep all the dotfiles for both asdf and other version managers. asdf has made it easy to work with multiple tools, like node, ruby, java, and we even had it for python at some point with detect-secrets. It makes this easy, and it behaves well and consistent for all tools. nvm works differently from rbenv for example. asdf is working the same for all tools, and only requires one change in the shell's rc file.

How is this RFC resolved?

Adding .tool-versions in all our repos, and later changing our setup scripts to use asdf.

kajatiger commented 1 year ago

I like the idea, but I have had several issues having rbenv and asdf at the same time and I think if we go with asdf we need to go with it all the way and make a versions file for all the repos and make sure we don't require rbenv for any project.

araujobarret commented 1 year ago

I remember suffering from some ruby Artsy repos with rbenv and asdf, and I guess most of them use rbenv.

erikdstock commented 1 year ago

I use asdf and like it- i think everyone should switch - but I don't know about requiring this class of tooling for all developers. asdf supports legacy tool version files: Just add legacy_version_file = yes to ~/.asdfrc. My initial thought is that using legacy version files and telling asdf to adapt seems preferable to me to adding another place to maintain these versions or requiring folks to change version managers.

On the topic of setup scripts, I'm personally in favor of just expecting developers to perform this step themselves. I always read them before running them and have a nagging fear of something like this sneaking in and messing up my machine.

cavvia commented 1 year ago

I'm not sure we can switch Python projects over from pyenv and pip, since asdf doesn't seem to support virtualenvs. Pyenv supports both version and virtualenv management and we use the latter feature heavily. I may be wrong, but I haven't found good documentation on how to do that with asdf.

kajatiger commented 1 year ago

On the topic of setup scripts, I'm personally in favor of just expecting developers to perform this step themselves. I always read them before running them and have a nagging fear of something like this sneaking in and messing up my machine.

I don't think this is a good idea considering the number of engineers that have to work together on the number of repos we have. In their private tinkering projects, devs can feel free to set up anything themselves how they want to, but in this collaborative context the restrictions of agreeing on a convention can reduce chaos and annoying setup/installation problems. The setup scripts are there to free up time for actual development that would otherwise be spent on installation. In terms of developer velocity definitely better to have a very straight forward setup script in every repo and to agree on some formal conventions for the tools and versions of tools we use.

erikdstock commented 1 year ago

The setup scripts are there to free up time for actual development that would otherwise be spent on installation. [@kajatiger]

I have had enough bad experiences over the years that I prefer to check these installation scripts before running - it seems very common for something to get out of date with a new architecture, or broken by a version update of some dependency, and when it does it often effects other projects as well; I just don't think it is a cure-all to rely on the scripts and developers should be expected to take some responsibility for maintaining system-level tools. But I agree with your general point that it wouldn't be any easier for developers to manage this all themselves across potentially dozens of repos. I think I would support

brainbicycle commented 1 year ago

Thanks for all the comments!

@erikdstock I think your bullets are a good next step for this RFC if there is no major opposition. This would not be a personal mandate, if someone prefers to use a different version manager they can continue to do so, long term though asdf would be the default where applicable and they may have to adapt a bit when setting up a repo to use their preferred version manager. We can of course not make this a hard switch and still keep support around for the other version managers in repos in the short term.

For the python concern, I think if there is a language or use case that asdf does not work well enough for our purposes it is fine to not use it. It would be a good enough win if 90% of our use cases can be covered by one version manager.

So e.g. nodejs, ruby, java we can support with asdf, so those repos we could add support for.

joeyAghion commented 1 year ago

I'm open to using asdf instead of nvm and rbenv if it works at least as well. Fewer tools are better than more tools, other things being equal.

In addition to updating the base setup script and at least one project to adopt this preference, I'd like to see the steps for cleanly switching from the previous defaults to this new default (e.g. unhooking rbenv and nvm shims), since this will affect multiple developers.

I'd also warn against trying to make the setup scripts cooperate with all possible preferences. Simpler to align them with a single default and clearly call that out.

P.S. This PR should probably update this playbook accordingly.