DEV Community

Cover image for Backend/Ops: One of the most powerful Software Development tool - 2 mins read
Burhanuddin Bhopalwala
Burhanuddin Bhopalwala

Posted on • Updated on

Backend/Ops: One of the most powerful Software Development tool - 2 mins read

Table Of Contents

  1. Tool Introduction
  2. Tool Management/Usage
  3. Best practices and tips ...

Tool Introduction

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.

Tool Management/Usage

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-versions file (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-versions file (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

asdf runtime/python installation

Another example:

asdf runtime/scala installation

Currently, with the help of asdf, I can easily manage all the below runtimes some with even multiple versions like for nodeJS, python etc.

asdf multiple runtime installations

Attaching the code block below.

❯ asdf plugin-list --urls --refs
act master 8729029
aws-vault master 937a1db
awscli main b9ba4c7
docker-slim master 4ee75a3
golang master 1f388f1
helm master 87eef5a
java master f0c702f
jq master 3144577
kubectl master da7bb0b
minikube master 8ca7b8d
mysql master 3aaf756
nodejs master cb61e3d
perl master 31bb799
php master 759843b
postgres master 4f8b356
python master 8ab052f
redis master bf1276e
ruby master f134c2d
sbt master 33f9637
scala master 1206055
skaffold master c942ecf
spark master 6fe49de
Enter fullscreen mode Exit fullscreen mode

Best practices and tips

1: Use of $HOME/.tool-versions

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.

For 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.

Global tool-versions

2: Use of $HOME/.asdfrc

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.

~/.asdfrc is the configuration file for managing asdf. As spells out from the file name it is based on cosmic config configuration.

For asdf to work with the legacy version file you need to turn on the switch for legacy_version_file under $HOME/.asdfrc.

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.

3: From my experience with this tool

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.

asdf built-in plugin not found

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 asdf let me tell you its a series of keys on your keyboard :)

Thanks for reading!

Connect 🤝:
Email: bbhopalw@gmail

For further reading ✍️:
Big Data & Cloud Engineering blogs:

Backend & Software Engineering blogs:

Top comments (0)