I need to jump between different versions of terraform, terragrunt, python, ... all the time for work. asdf is an absolute asset and makes that so much easier. I can heavily recommend giving it a try! I've even embedded it into our default CI image, as it allows me to very easily install consistent versions of many utilities, while also allowing to override versions by choice afterwards.
I love asdf. I was a big fan of rbenv and nodenv but it has completely supplanted both of those for me. It uses a very similar model and CLI.<p>Nearly every lang on my machine is managed by asdf. It's been a while since I last tried but I seem to recall golang and JVM stuff seemed to play better with the default installers.<p>Anyway, between asdf, homebrew, and my dotfiles setup, I can have a brand new machine up and running with all my favorite stuff in about 20 minutes.
I'm a huge fan of asdf and have been using for years together with direnv! It's great to see how much effort is put into it! I hope more people adopt it so that we don't have to `curl | sh`! One thing I have issues with asdf is security as are no checksums, so, you if I project get compromised you'll get compromised, too. This, of course, is in addition to the third-party asdf plugin getting itself compromised (which is the greater risk). Last, but not least - I wish asdf came with something like eget [0] incorporated so that it can install 99% of the plugins directly and safely! Last, but not least - 99% of the plugins have almost identical code and all that changes is the repo, so, this should be generalized. For example, many years ago I made just one codebase of all HashiCorp plugins [1] and it's been working great!<p>[0]: <a href="https://github.com/zyedidia/eget" rel="nofollow">https://github.com/zyedidia/eget</a><p>[1]: <a href="https://github.com/asdf-community/asdf-hashicorp" rel="nofollow">https://github.com/asdf-community/asdf-hashicorp</a>
I have been gradually moving from asdf to nix shell plus direnv combo. It handles system level dependent packages in addition to programming language version. Pinning the exact version is not a first class feature as of today, though possible by pinning the nixpkg to a specific commit. Hopefully nix flakes will solve this use case well when it is stable.
I thought that this was going to be about ASDF (Another System Definition Facility; a module manager for Common Lisp): <a href="https://asdf.common-lisp.dev/" rel="nofollow">https://asdf.common-lisp.dev/</a><p>Turns out that it’s a version manager (now there’s another overloading: ‘VM’ to mean ‘version manager’ vice ‘virtual machine’): <a href="https://github.com/asdf-vm/asdf" rel="nofollow">https://github.com/asdf-vm/asdf</a>
Asdf is a good idea in theory and pretty okay considering it's in Bash, but the execution is quite lackluster. I'm glad the maintainer is focusing on performance, but there are other areas that prevent me from using the tool:<p>- asdf uses way more commands than it needs to. Instead of glob pattern matching for files, it reads the output of `ls` (and _many_ very similar mistakes)<p>- When running functions, the output tends to be collected using $(). Since this is done so much, this realllyyyy slows down execution since subshell invocations are slowwww in bash. Better is to set the global variable `REPLY` and use that directly from the callee<p>- The command line interface is kind of verbise and clunky and a little unintuitive<p>- There are too many separate plugins to use and download. Too much code duplication between plugins<p>I hope this doesn't sound like a laundry list of gripes, but just things to improve upon for the maintainers - I understand how hard it is to write Bash that works everywhere. Personally, I've opted to build my own (partial) solution that implements these suggestions at <a href="https://github.com/hyperupcall/woof" rel="nofollow">https://github.com/hyperupcall/woof</a>, but my hope is that asdf will become substantially better over the years
I love asdf but the one thing that bugs me is that running `asdf install` inside a folder containing a .tool-versions file won't automatically install the plugins needed to install the tools mentioned in that file. You first have to install the required plugins by hand[0]. Makes it very annoying to use in CI/CD pipelines.<p>[0]: <a href="https://github.com/asdf-vm/asdf/issues/1298" rel="nofollow">https://github.com/asdf-vm/asdf/issues/1298</a>
I've been using asdf for awhile because it's was good and much easier than having a language version manager for every language I was using. Asdf was always pretty good, but I'd sometimes see slowness and starship (my prompt) would occasionally complain that the shims were taking too long.<p>As languages that I'm using are starting to adopt their own version manager (rust/go), I'm left using asdf pretty much exclusively for node and my eyes wander to some of the node-only tools like volta and fnm which use rust and I wondered if people were watching performance. Glad somebody is.
> ve already written a tool for generating flame graphs of Bash scripts so stay tuned.<p>I know I'm focusing on the wrong thing, but this is cool
I'm happy my team switched off asdf, it's not ready for prime time. It has baffling bugs, like selecting the wrong version of installed tools. It introduces asdf specific problems that you have to debug to use it for daily activities. I do not recommend it.
I have never personally used asdf, but working as DevOps I had to help many fellow Devs untangle their environments because they messed up with asdf and everything broke down. One time someone installed it on a build server to try to manage python binaries and all builds stopped working.<p>Maybe if I got some time to explore the tool I would have a better appreciation for it, but from my experience it is too easy to mess things up.
Really happy to see someone actually caring about performance in tooling, even if the conclusion for now is that it has gotten worse over time until now!
Slightly OT, there is an npm package also called asdf, it allows you to start a static dev server at the current directory. All you need to do is just `npx asdf`. I have no idea how I discovered this package, but it is really convenient as I have used it multiple times. (I know there is a python equivalent command, but `npx asdf` is probably shorter.)
asdf + direnv is how I avoid the performance hit of the shims completely. For me that's the sweetspot of developer ergonomics, performance and reproducibility of the dev env.
I've been avoiding using asdf because I hate its global shims. asdf-direnv may have a configuration now that doesn't require them, I need to take another look.
Is bash the bottleneck? Given the linked issue regarding comments in the file slowing down the commands, it makes me think so.
Why not rewrite it in another PL?