I've been using it and has contributed to it, but I wish it supported out of the box GitHub-based release binaries as 90% of my code for different vendors was relatively the same, so, instead of having multiple identical repositories, I created one, which uses introspection [0].
I wish this was available out of the box to handle literary 90% of the tools.
Also, I typically pair it with direnv [1] for even more magic.
Seeing all the love for direnv makes me feel like I'm the only one taking crazy pills.
Direnv breaks referential transparency of the shell. I heavily use my shell history to riff on commandlines I've entered in the past. If direnv is in the mix, my shell pipelines sometimes have to have `cd` in them, often in subshells because that works better for me than pushd/popd.
pyenv/rbenv/asdf do the same thing, but you can have a "global" version pinned and do all your shell-related package installs there, so it doesn't end up being that bad. Though, this still breaks when I happen to be sitting in a directory on my system that has a .python-version file. All of a sudden my "global"ly installed python packages don't work. I greatly prefer tools like pipx / pipsi for this purpose (is there a language-agnostic pipx-alike? or is that nix?) because the shims they install usually work no matter what my shell environment/CWD is.
.... Maybe most of my ire is because my only exposure to direnv is because at least one repo at my day job uses it. For me it's not so much "customize your environment any way you want", it's "oh did you run that command from projectdir/foo instead of projectdir/foo/bar? That doesn't work". Debugging the interactions between people's individual poetry/pipenv/pip/rbenv/direnv/etcetcetc setups and project-based setups is the bane of my work life.
I've also written a handful of plugins for asdf, and this is exactly my experience also - I even used the asdf-hashicorp library as the basis for https://github.com/vmware-tanzu/asdf-carvel
Seems like a lot of duplicated work across all these plugins
Can this replace the broken and horrible tools of rbenv, pyenv, and pipenv? I shudder whenever a new version comes out what it does to my shell when I have a broken version (included as the latest from the output from pyenv globals or some such)
I just woke up to find this thread on home page and read all the comments.
Thank you for the feedback. I’ll ping the team to let them know about this thread.
The plugins were kept as separate repos - like Heroku Buildpacks, because I never had the time to vet/review them. I had written plugins for Ruby, Node.js, Erlang and Elixir because those are the ones I wanted. I did not expect the project to be active this long or have these many contributors, maintainers and users.
We’ll bring back the readme in the repo with usage instructions.
P.S: Author here. Not an active maintainer except helping clean issues
We use it at GitLab since a few months in order to manage our development toolchain [0]. Before we had people using rvm, rbenv, nvm, homebrew, system packages and everything in between. Supporting our engineers and non-engineers has been a lot easier since asdf, and the whole version manager related issues calmed down a bit.
The only thing I miss from homebrew is the pre-compiled stuff like e.g. Postgres or redis
I've been using it since 2017 for an Elixir/Phoenix backend, React frontend and PostgreSQL database. It works very well and spares me from having to use three language managers (one for Elixir, one for Erlang and one for JS) plus a docker container for PostgreSQL. I was pleasantly surprised that it manages the database too.
My install of asdf at some point broke so badly, I could not get anything to run. I wish I remembered the exact trouble, but it was bad enough that I just un-installed it in favor of `nvm` for node versioning, and never looked back.
My greatest asdf wish (well, I guess not greatest since I've never taken the time to submit a patch...) is for supporting pre-compiled Erlang (see https://github.com/asdf-vm/asdf-erlang/issues/120). It's often an adventure getting the whole team updated whenever we bump our Erlang version.
I am using it for python, erlang, elixir and nodejs. It works great on MacOS so far. I used to use a mix of homebrew versions of those tools and some language-specific install scripts like kerl or pyenv.
One of my favorite things is to quickly start a new shell with a specific version to test something: 'asdf shell python $ver'.
I did try direnv as others mentioned here, but I found it a bit too magical and eventually abandoned it.
It's growing in popularity in the Rails community (probably because Rails now requires both Ruby and Node). Previously I recommended chruby in my installation guide for Ruby [0] and Rails [1], but after doing an informal survey of Rails users, I now show how to use asdf.
"Please head over the documentation site" is a link back to the site. The ballad links to an old repo (fortunately Github redirects it) The all-plugins page 404's.
After giving up on the website I look at the code. It's a shell script. Wonderful.
I wanted to see what the differences between asdf and nix were, and found a pretty lengthy article[1] that explained it quite well in the first few paragraphs. asdf is better than nothing, and better than multiple version managers for each language in one project, but it is a far cry from the portability and reliability of nix.
If you wanna do something quickly to ease the pain of version management, asdf is there, helpful, and ergonomic. But if you want to make version management an issue of the past and fix it for good, nix is the way to go.
So they both have their use. nix just feels more proper.
asdf makes my life so much easier seriously, it's amazing. Try it!
I have a .tool-versions file in code repo that lists what I need for a project.
elixir 1.2.3
erlang 1.2.3
nodejs 1.2.3
Whenever I `cd` into the folder, asdf automatically uses the right versions for me. I don't have to worry about anything. Razer sharp scalpel of a tool.
The only issue is (was?) that you need to preinstall these unless this has changed in the past year. When I integrated it with direnv [0], I made the missing ones autoinstall.
.tool-versions means everyone on the team knows which version(s) to use for a project, for anything outside of docker. Auto-install is an awesome feature, too.
Asdf is fantastic for forcing versions of elixir, especially since no native version control exists for the elixir vm itself. Tools like this are developer friendly and also easy to introduce and share - I've had nothing but fantastic experiences with Asdf.
ASDF is great. I've been using it for four years now with no real complaints.
It's made collaboration with contractors much easier to just be able to drop a .tool-versions file into a project and know that regardless of what OS each of us are on, we'll have the same language versions.
We started using this for elixir/erlang and quickly replaced all the other version managers company-wide. The only issue we've really had is that sometimes people don't understand reshim and when they need to do it.
It's for switching versions of your local CLI tools quickly.
> asdf is a CLI tool that can manage multiple language runtime versions on a per-project basis. It is like gvm, nvm, rbenv & pyenv (and more) all in one! Simply install your language’s plugin!
For example:
$ asdf global python 3.6.2
$ python -V
Python 3.6.2
$ asdf local python 3.9.1
$ python -V
Python 3.9.1
"asdf local" stores the version to use for the current directory across shells, which is neat. "shell" is for the current session, and "global" is for the system.
Tried asdf few months ago but couldn't get warm with it. Went back to nvm for node and just venv/ for Python. Anyone went back too and if yes, why? Thinking of giving it another try.
Could this tool be used to create a meant a software bill of materials, or is there more work needed for that effort?
> A bill of materials or product structure (sometimes bill of material, BOM or associated list) is a list of the raw materials, sub-assemblies, intermediate assemblies, sub-components, parts, and the quantities of each needed to manufacture an end product. [0]
I've had mostly good experience with asdf except last month when I tried to get it working on an m1 Mac. Eventually gave up and just brew installed everything (erlang, elixir, nodejs, java. New work laptop that only needed one version of everything for now). There's an open issue on the project for support.
Later on I ran into still more problems on the m1 and convinced a project manager to take it and got an Intel Mac instead and back to blissful working asdf.
[+] [-] nescioquid|5 years ago|reply
[+] [-] samatman|5 years ago|reply
Isn't there some other part of the keyboard they could have mashed?
[+] [-] dj_mc_merlin|5 years ago|reply
[+] [-] Snarwin|5 years ago|reply
https://github.com/asdf-format/asdf
[+] [-] JasonFruit|5 years ago|reply
[+] [-] phito|5 years ago|reply
[+] [-] nikolay|5 years ago|reply
I wish this was available out of the box to handle literary 90% of the tools.
Also, I typically pair it with direnv [1] for even more magic.
[0]: https://github.com/Banno/asdf-hashicorp
[1]: https://direnv.net/
[+] [-] philsnow|5 years ago|reply
Direnv breaks referential transparency of the shell. I heavily use my shell history to riff on commandlines I've entered in the past. If direnv is in the mix, my shell pipelines sometimes have to have `cd` in them, often in subshells because that works better for me than pushd/popd.
pyenv/rbenv/asdf do the same thing, but you can have a "global" version pinned and do all your shell-related package installs there, so it doesn't end up being that bad. Though, this still breaks when I happen to be sitting in a directory on my system that has a .python-version file. All of a sudden my "global"ly installed python packages don't work. I greatly prefer tools like pipx / pipsi for this purpose (is there a language-agnostic pipx-alike? or is that nix?) because the shims they install usually work no matter what my shell environment/CWD is.
.... Maybe most of my ire is because my only exposure to direnv is because at least one repo at my day job uses it. For me it's not so much "customize your environment any way you want", it's "oh did you run that command from projectdir/foo instead of projectdir/foo/bar? That doesn't work". Debugging the interactions between people's individual poetry/pipenv/pip/rbenv/direnv/etcetcetc setups and project-based setups is the bane of my work life.
[+] [-] mwudka1|5 years ago|reply
[+] [-] s0l1dsnak3123|5 years ago|reply
Seems like a lot of duplicated work across all these plugins
[+] [-] dnautics|5 years ago|reply
[+] [-] ahawkins|5 years ago|reply
[+] [-] nine_k|5 years ago|reply
(My favorite worth-1000-words picture about that is e.g. here: http://www.tshirtvortex.net/free-magic/)
[+] [-] burlesona|5 years ago|reply
[+] [-] johnwyles|5 years ago|reply
[+] [-] SingAlong|5 years ago|reply
Thank you for the feedback. I’ll ping the team to let them know about this thread.
The plugins were kept as separate repos - like Heroku Buildpacks, because I never had the time to vet/review them. I had written plugins for Ruby, Node.js, Erlang and Elixir because those are the ones I wanted. I did not expect the project to be active this long or have these many contributors, maintainers and users.
We’ll bring back the readme in the repo with usage instructions.
P.S: Author here. Not an active maintainer except helping clean issues
[+] [-] leipert|5 years ago|reply
The only thing I miss from homebrew is the pre-compiled stuff like e.g. Postgres or redis
[0]: https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge...
[+] [-] pmontra|5 years ago|reply
[+] [-] pavel_lishin|5 years ago|reply
[+] [-] dceddia|5 years ago|reply
[+] [-] TheRealPomax|5 years ago|reply
[+] [-] bismark|5 years ago|reply
[+] [-] rdtsc|5 years ago|reply
One of my favorite things is to quickly start a new shell with a specific version to test something: 'asdf shell python $ver'.
I did try direnv as others mentioned here, but I found it a bit too magical and eventually abandoned it.
[+] [-] DanielKehoe|5 years ago|reply
[0]: [https://mac.install.guide/ruby/index.html] [1]: [https://learn-rails.com/install-rails-mac/index.html]
[+] [-] Mathnerd314|5 years ago|reply
After giving up on the website I look at the code. It's a shell script. Wonderful.
I'll stick with Nix any day. Or maybe conda.
[+] [-] kemayo|5 years ago|reply
[+] [-] iFreilicht|5 years ago|reply
If you wanna do something quickly to ease the pain of version management, asdf is there, helpful, and ergonomic. But if you want to make version management an issue of the past and fix it for good, nix is the way to go.
So they both have their use. nix just feels more proper.
[+] [-] vages|5 years ago|reply
[+] [-] xfer|5 years ago|reply
[+] [-] viraptor|5 years ago|reply
[+] [-] marius_k|5 years ago|reply
[deleted]
[+] [-] sergiotapia|5 years ago|reply
I have a .tool-versions file in code repo that lists what I need for a project.
Whenever I `cd` into the folder, asdf automatically uses the right versions for me. I don't have to worry about anything. Razer sharp scalpel of a tool.[+] [-] richjdsmith|5 years ago|reply
[+] [-] nikolay|5 years ago|reply
[0]: https://direnv.net/
[+] [-] pensatoio|5 years ago|reply
.tool-versions means everyone on the team knows which version(s) to use for a project, for anything outside of docker. Auto-install is an awesome feature, too.
[+] [-] burlesona|5 years ago|reply
The name is off putting to me though, because it’s meaningless. Maybe I could alias it to something like xenv and pretend it didn’t bother me.
[+] [-] 1123581321|5 years ago|reply
[+] [-] koolk3ychain|5 years ago|reply
[+] [-] AlchemistCamp|5 years ago|reply
It's made collaboration with contractors much easier to just be able to drop a .tool-versions file into a project and know that regardless of what OS each of us are on, we'll have the same language versions.
[+] [-] vlunkr|5 years ago|reply
[+] [-] whitepoplar|5 years ago|reply
[+] [-] mamcx|5 years ago|reply
[+] [-] momothereal|5 years ago|reply
> asdf is a CLI tool that can manage multiple language runtime versions on a per-project basis. It is like gvm, nvm, rbenv & pyenv (and more) all in one! Simply install your language’s plugin!
For example:
"asdf local" stores the version to use for the current directory across shells, which is neat. "shell" is for the current session, and "global" is for the system.The supported CLI tools is extendable via plugins: https://asdf-vm.com/#/plugins-all
[+] [-] e12e|5 years ago|reply
Main benefit is you no longer need N half-baked utilities fighting over your path and shell completions, just asdf.
And plug-ins mostly re-use other tools, so it's both simple to set up and mostly avoids duplicating effort.
[+] [-] desmap|5 years ago|reply
[+] [-] tareqak|5 years ago|reply
> A bill of materials or product structure (sometimes bill of material, BOM or associated list) is a list of the raw materials, sub-assemblies, intermediate assemblies, sub-components, parts, and the quantities of each needed to manufacture an end product. [0]
[0] https://en.wikipedia.org/wiki/Bill_of_materials
[+] [-] gangstead|5 years ago|reply
Later on I ran into still more problems on the m1 and convinced a project manager to take it and got an Intel Mac instead and back to blissful working asdf.
[+] [-] dustfinger|5 years ago|reply