Backend/Ops: One of the most powerful Software Development tool - 2 mins read
Tags: productivity, programming, microservices, devops
Published: 2022-01-01 10:40:45

## Table Of Contents
   1. [Tool Introduction](#chapter-1)
   2. [Tool Management/Usage](#chapter-2)
   3. [Best practices and tips](#chapter-3)
...

### Tool Introduction <a name="chapter-1"></a>

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](asdf-vm.com).

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 <a name="chapter-2"></a>

You can easily install `asdf` from [here](http://asdf-vm.com/guide/getting-started.html#_3-install-asdf). 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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/x3rz1g87rjymltfvcpjf.png)

**Another example:**

![asdf runtime/scala installation](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9f3pfh3w0ox09yks4hip.png)

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/h1bk2j9h8veeme9drfzj.png)

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
```

### Best practices and tips <a name="chapter-3"></a>

#### 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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fv5esgjgrnafenhlacow.png)

#### 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](ide/getting-started.html#using-existing-tool-version-files).


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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c6j62fva8es0tjci7i1o.png)

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
Linkedin: www.linkedin.com/in/bbhoaplw

---

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