Hello everyone! In this short article, I wanted to share with the DEV community here a utility tool that immensely helped me in 2021 for managing and developing the Software(s) I worked on.
I am talking about
asdf. While most of the PRO developers out there are aware of it. This article is to share with community members who are unaware of this like I was a few months back.
asdf is a CLI tool for managing multiple runtime(s) via extendable plugins - docs at asdf.
With this one single CLI tool, not only you can manage and switch to multiple runtime/s and its version/s but can also simply avoid the installation overhead. Thus, having a levy to switch the runtime versions in between projects you are working on.
So how does it works? I will be explaining this in brief in the following content.
You can easily install
asdf from here. It has all the details and has good documentation available.
So, It's really simple,
asdf for each runtime uses a
git plugin. A plugin shares one-to-one mapping with the runtime you want to install. After adding a plugin you can now install multiple versions of the runtime using the same plugin. Here are the simple 4 steps:
Search for a plugin
asdf plugin-list-all | grep python
Install/Add a plugin
asdf plugin-add python
Install a runtime version of your choice, default is the latest stable head/version
asdf install python latest
asdf global python latest
Above command will make an entry into an
$HOME/.tool-versionsfile (more details to follow on this config file)
- You can not install other runtime versions by repeating the above step no need to add a plugin as it's a one-time process
asdf install python 3.8.7
asdf local python 3.8.7
Above command will make an entry into an
$WORK_DIR/.tool-versionsfile (more details to follow on this config file)
By using local scope you can set the asdf version for local project scope runs on python 3.8.7 and not on python latest/3.10.1
Currently, with the help of
asdf, I can easily manage all the below runtimes some with even multiple versions like for
Attaching the code block below.
❯ asdf plugin-list --urls --refs act https://github.com/grimoh/asdf-act.git master 8729029 aws-vault https://github.com/beardix/asdf-aws-vault.git master 937a1db awscli https://github.com/MetricMike/asdf-awscli.git main b9ba4c7 docker-slim https://github.com/everpeace/asdf-docker-slim.git master 4ee75a3 golang https://github.com/kennyp/asdf-golang.git master 1f388f1 helm https://github.com/Antiarchitect/asdf-helm.git master 87eef5a java https://github.com/halcyon/asdf-java.git master f0c702f jq https://github.com/ryodocx/asdf-jq.git master 3144577 kubectl https://github.com/asdf-community/asdf-kubectl.git master da7bb0b minikube https://github.com/alvarobp/asdf-minikube.git master 8ca7b8d mysql https://github.com/iroddis/asdf-mysql.git master 3aaf756 nodejs https://github.com/asdf-vm/asdf-nodejs.git master cb61e3d perl https://github.com/ouest/asdf-perl.git master 31bb799 php https://github.com/asdf-community/asdf-php.git master 759843b postgres https://github.com/smashedtoatoms/asdf-postgres.git master 4f8b356 python https://github.com/danhper/asdf-python.git master 8ab052f redis https://github.com/smashedtoatoms/asdf-redis.git master bf1276e ruby https://github.com/asdf-vm/asdf-ruby.git master f134c2d sbt https://github.com/bram2000/asdf-sbt.git master 33f9637 scala https://github.com/asdf-community/asdf-scala.git master 1206055 skaffold https://github.com/virtualstaticvoid/asdf-skaffold.git master c942ecf spark https://github.com/joshuaballoch/asdf-spark.git master 6fe49de
I want to share some useful tips to make full use of
asdf. For most of the runtimes (particularly for a programming language(s), we maintain a version file as a satellite file inside the project.
For python it is
.python-version, for nodeJS it is
.nvmrc and for RoR it is
.ruby-version. These files are recognized as legacy files to
asdf that satellite file is called
.tool-versions. You can maintain one copy under a
$HOME/.tool-versions directory to mention the version you want to use globally.
For local projects, you can add another
.tool_verisons file under
$WORK_DIR/.tool-versions. So every time you check-in into the project
asdf knows which version to switch for a particular runtime.
This is what my
~/.tool-versions file looks like (globally) attaching for reference.
You may not want to use/manage multiple satellite files just for the sake of auto-switching of the runtime version. In such a case we can you one config file
~/.asdfrc is the configuration file for managing
asdf. As spells out from the file name it is based on cosmic config configuration.
asdf to work with the legacy version file you need to turn on the switch for
legacy_version_file = yes
If this config is turned on it means that
asdf can globally/locally pick the versions based on the legacy file if the
.tool-versions file is not found. More details here.
A more generic use case is to have one
.tool-versions file for a project which builds on using multiple runtimes of a particular version. It makes lots of sense to switch to a single
.tool-versions file instead of maintaining multiple
legacy files. O/w in most cases legacy files are usually preferred! and
asdf support that as well via the
.asdfrc config file as mentioned above.
It may happen that for some runtimes/tools you are not able to install/list a plugin, in such cases, a google search will help. For example below plugin URL for
aws-vault, I found by searching on Google.
I hope, this article may help the DEV community who are unaware of this highly productive utility tool for software development, till the time of reading this post.
It not only help to manage multiple runtime(s) in a single click but at the same time helps in avoiding all the installation overhead and conflicts among them.
Lastly, you might be wondering about the full form/meaning of
asdflet me tell you its a series of keys on your keyboard :)
Thanks for reading!
For further reading ✍️:
Big Data & Cloud Engineering blogs:
- Towards Data Science & AV Publication: https://medium.com/@burhanuddinbhopalwala
Backend & Software Engineering blogs:
- DEV Community: https://dev.to/burhanuddinbhopalwala