3 ms·

In a very quick & dirty read I couldn't understand what it's for. Could someone give me a practical example? I think a practical example is lacking in the intro

In a very quick & dirty read I couldn't understand what it's for. Could someone give me a practical example? I think a practical example is lacking in the introduction.

brigandish 4y ago
I feel your pain, I always upvote people who summarise links on HN because so often the linked info leaves me in the dark! There was a discussion about asdf before[1] with a blog post[2] about someone's shift to using asdf which may help, it's pretty straight to the point. [1] https://news.ycombinator.com/item?id=30917354 https://news.ycombinator.com/item?id=30917354 [2] https://jinyuz.dev/2020/07/switching-from-pyenv-rbenv-goenv-and-nvm-to-asdf/ https://jinyuz.dev/2020/07/switching-from-pyenv-rbenv-goenv-...
bxparks 4y ago
My problem is that I know what it's for, but I don't understand how it works. The referenced page contains a "How It Works" section, but it gives me no useful information: > Once asdf core is set up with your Shell configuration, plugins are installed to manage particular tools. When a tool is installed by a plugin, the executables that are installed have shims created for each of them. When you try and run one of these executables, the shim is run instead, allowing asdf to identify which version of the tool is set in .tool-versions and execute that version. There is a hyperlink on word shims to the Wikipedia article https://en.wikipedia.org/wiki/Shim_(computing) https://en.wikipedia.org/wiki/Shim_(computing) that explains the generic concept of shims. Not helpful.
- rzzzt 4y ago
  Most likely $PATH and variables like eg. $JAVA_HOME get modified so that asdf captures any invocation to commands like "python" in the shell, and runs its own code instead of /usr/bin/python. Then it can decide which version of Python to defer to. Edit: here it is: https://github.com/asdf-vm/asdf/blob/v0.10.2/asdf.sh#L30-L31 https://github.com/asdf-vm/asdf/blob/v0.10.2/asdf.sh#L30-L31
letmeinhere 4y ago
The most common need for this kind of thing is when you write software that targets a very specific version of a given binary (e.g. a ruby/python/node interpreter) and that version differs from what you have installed globally. This is often the case when the software you are writing is a web application that has one intended production deployment target, rather than a library or even a shrink-wrapped product that might need to work in diverse installations. If you just have one of these projects, you can just install the dependency in user-space and update your user's startup files to point to it and be happy. But if you have two or more, or the version changes often (hopefully it does, so you can scoop up security and other updates), then a version manager helps with the toil of swapping back and forth. Like many of its predecessors, asdf not only gives you a set of commands to swap these versions on demand, but it also creates "shims" to automate this swapping behavior when you enter and exit directories with an appropriate configuration file. The "killer feature" of asdf (versus rbenv, pyenv, phpenv etc.) is that it is an extendable toolkit that gives you the same tools for dozens, maybe hundreds of different plugins contributed by the community. It is a polyglot web programmer's friend.
cdumler 4y ago
I think what you're missing is that language runtimes typically install themselves globally, and major release versions typically have issues with backwards compatibility. If you install Ruby 3 globally, your Ruby on Rails project programmed on Ruby 2 may not work. Thus, there is a need to be able to install multiple versions of runtimes, and the ability to cause a particular version of a runtime to be used depending on the project you are in. This allows the development team to decide if and when to make runtime version changes. My team maintains multiple projects that are over 10 years old with a mix of Ruby on Rails and JavaScript. The code base is large, so there is pretty much a guarantee that going to the next version of Ruby or Ruby on Rails or Node will introduce problems. We lock down all the versions for everything so that we don't have to worry a deploying to a new environment (new server, developer, etc) will have different versions and require use to change priority to fix things. Instead, we periodically review our projects for upgrades, find upgrade issues and fix them, lock new versions, and deploy. Some of the code base is in legacy status. It does what it needs to do, and we have no need to change it unless some security issue is found.

In a very quick & dirty read I couldn't understand what it's for. Could someone give me a practical example? I think a practical example is lacking in the introduction.

brigandish 4y ago

I feel your pain, I always upvote people who summarise links on HN because so often the linked info leaves me in the dark! There was a discussion about asdf before[1] with a blog post[2] about someone's shift to using asdf which may help, it's pretty straight to the point. [1] https://news.ycombinator.com/item?id=30917354 https://news.ycombinator.com/item?id=30917354 [2] https://jinyuz.dev/2020/07/switching-from-pyenv-rbenv-goenv-and-nvm-to-asdf/ https://jinyuz.dev/2020/07/switching-from-pyenv-rbenv-goenv-...

bxparks 4y ago

My problem is that I know what it's for, but I don't understand how it works. The referenced page contains a "How It Works" section, but it gives me no useful information: > Once asdf core is set up with your Shell configuration, plugins are installed to manage particular tools. When a tool is installed by a plugin, the executables that are installed have shims created for each of them. When you try and run one of these executables, the shim is run instead, allowing asdf to identify which version of the tool is set in .tool-versions and execute that version. There is a hyperlink on word shims to the Wikipedia article https://en.wikipedia.org/wiki/Shim_(computing) https://en.wikipedia.org/wiki/Shim_(computing) that explains the generic concept of shims. Not helpful.

rzzzt 4y ago
Most likely $PATH and variables like eg. $JAVA_HOME get modified so that asdf captures any invocation to commands like "python" in the shell, and runs its own code instead of /usr/bin/python. Then it can decide which version of Python to defer to. Edit: here it is: https://github.com/asdf-vm/asdf/blob/v0.10.2/asdf.sh#L30-L31 https://github.com/asdf-vm/asdf/blob/v0.10.2/asdf.sh#L30-L31

letmeinhere 4y ago

The most common need for this kind of thing is when you write software that targets a very specific version of a given binary (e.g. a ruby/python/node interpreter) and that version differs from what you have installed globally. This is often the case when the software you are writing is a web application that has one intended production deployment target, rather than a library or even a shrink-wrapped product that might need to work in diverse installations. If you just have one of these projects, you can just install the dependency in user-space and update your user's startup files to point to it and be happy. But if you have two or more, or the version changes often (hopefully it does, so you can scoop up security and other updates), then a version manager helps with the toil of swapping back and forth. Like many of its predecessors, asdf not only gives you a set of commands to swap these versions on demand, but it also creates "shims" to automate this swapping behavior when you enter and exit directories with an appropriate configuration file. The "killer feature" of asdf (versus rbenv, pyenv, phpenv etc.) is that it is an extendable toolkit that gives you the same tools for dozens, maybe hundreds of different plugins contributed by the community. It is a polyglot web programmer's friend.

cdumler 4y ago

I think what you're missing is that language runtimes typically install themselves globally, and major release versions typically have issues with backwards compatibility. If you install Ruby 3 globally, your Ruby on Rails project programmed on Ruby 2 may not work. Thus, there is a need to be able to install multiple versions of runtimes, and the ability to cause a particular version of a runtime to be used depending on the project you are in. This allows the development team to decide if and when to make runtime version changes. My team maintains multiple projects that are over 10 years old with a mix of Ruby on Rails and JavaScript. The code base is large, so there is pretty much a guarantee that going to the next version of Ruby or Ruby on Rails or Node will introduce problems. We lock down all the versions for everything so that we don't have to worry a deploying to a new environment (new server, developer, etc) will have different versions and require use to change priority to fix things. Instead, we periodically review our projects for upgrades, find upgrade issues and fix them, lock new versions, and deploy. Some of the code base is in legacy status. It does what it needs to do, and we have no need to change it unless some security issue is found.