mirror of
https://github.com/asdf-vm/asdf.git
synced 2024-11-15 01:28:17 -07:00
Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more
bc95d68e4a
This change enables `asdf`'s existing latest-version-resolution functionality within the `.tool-versions` file itself. Rather than having to have a `.tool-versions` file that contains a full version number: ``` java corretto-21.0.5.11.1 ``` ...you can now use the same `latest:` syntax that is already available in the `local` & `global` commands, ie: ``` java latest:corretto-21 ``` ### Use case For many tool/runtime ecosystems (eg Java), if a program runs correctly under a specific version of that runtime, it can generally be relied on to run correctly under any _later_ version of that runtime with the same major version number (eg if a project runs under Corretto Java 21.0.5.11.1, it will run on any _later_ version of Corretto Java 21). This means that for projects in those ecosystems, there is little incentive to pin to fully-specified versions like `21.0.5.11.1`, and in fact there are downsides - over time, developers will default to using older, unpatched versions of Java, unless they are assiduous in continually updating the contents of the `.tool-versions` file, or have tooling devoted to doing so. At the Guardian we have several hundred projects that run on the Java platform, and due to our security obligations we generally want to be running under the _latest_ security-patched version of the Java runtime that matches our major-version requirement. We love `asdf` as a tool, and like that the `.tool-versions` file can become a source-of-truth documenting which version of Java a project uses, but we don't want to have to commit fully-specified version numbers like `21.0.5.11.1` to source control, or set up tooling to increment those version numbers across those hundreds of repositories. Allowing the use of `latest:` in the `.tool-versions` file means that we don't need to continually update those `.tool-versions` files. It also partially addresses some of the needs raised by https://github.com/asdf-vm/asdf/issues/1736, though this solution uses the existing `asdf` version-resolution functionality, rather than adopting the version requirements system used in nodejs. ### Implementation A new `resolve_version_spec()` function has been extracted from the existing `version_command()` function. This takes a version-spec string, like `latest:corretto-11` or `corretto-21.0.5.11.1`, and resolves it to a precise version number. This new `resolve_version_spec()` function is now also called in `select_version()`, used by `with_shim_executable()`, meaning that any execution of the `asdf` shim (eg, executing `java`) will now resolve any version specifications found in the `.tool-versions` file - if `.tool-versions` contains `java latest:corretto-21`, this will be resolved and the latest version of Java 21 used. ## Other Information Previous `asdf` PRs relating to `latest`: * https://github.com/asdf-vm/asdf/pull/575 in November 2019: added the `latest` command, eg `asdf latest python 3.6` reports the latest version of Python 3.6. * https://github.com/asdf-vm/asdf/pull/633 in July 2021: made it possible to specify `latest` when using the `local` & `global` commands, eg: `asdf local python latest:3.7` - this would save a precise version number to `.tools-versions`, which is undesired behaviour for us at the Guardian. A couple of Guardian systems attempting to standardise on using `.tool-versions` as a source of truth: * https://github.com/guardian/gha-scala-library-release-workflow/pull/36 * https://github.com/guardian/setup-scala |
||
|---|---|---|
| .github | ||
| bin | ||
| completions | ||
| docs | ||
| lib | ||
| scripts | ||
| test | ||
| .editorconfig | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| .tool-versions | ||
| asdf.elv | ||
| asdf.fish | ||
| asdf.nu | ||
| asdf.ps1 | ||
| asdf.sh | ||
| ballad-of-asdf.md | ||
| CHANGELOG.md | ||
| CONTRIBUTING.md | ||
| defaults | ||
| help.txt | ||
| LICENSE | ||
| README.md | ||
| SECURITY.md | ||
| version.txt | ||
asdf 
Manage multiple runtime versions with a single CLI tool, extendable via plugins - docs at asdf-vm.com
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!
Why use asdf?
- single CLI for multiple languages
- consistent commands to manage all your languages
- single global config keeping defaults in one place
- single
.tool-versionsconfig file per project - support for existing config files
.node-version,.nvmrc,.ruby-versionfor easy migration - automatically switches runtime versions as you traverse your directories
- simple plugin system to add support for your language of choice
- shell completion available for common shells (Bash, Zsh, Fish, Elvish)
Documentation
Please head over to the documentation site for more information!
- Getting Started
- All Commands
- All Plugins
- Create a Plugin with our asdf-plugin-template
- asdf GitHub Actions
Contributing
See CONTRIBUTING.md in the repo or the Contributing section on the docs site.
Community & Questions
- FAQ
GitHub Issues: report a bug or raise a feature request to the asdfcore team
StackOverflow Tag: see existing Q&A for asdf. Some of the core team watch this tag in addition to our helpful community
Ballad of asdf
Once upon a time there was a programming language
There were many versions of it
So people wrote a version manager for it
To switch between versions for projects
Different, old, new.Then there came more programming languages
So there came more version managers
And many commands for themI installed a lot of them
I learnt a lot of commandsThen I said, just one more version manager
Which I will write insteadSo, there came another version manager
asdf version manager - https://github.com/asdf-vm/asdfA version manager so extendable
for which anyone can create a plugin
To support their favourite language
No more installing more version managers
Or learning more commands
This was the mail I wrote to a few friends to tell them about the project. Thanks to @roshanvid for suggesting that this go into the readme