Our in-house editor recommended we don’t start with a sentence – “As the way we build software is
changing rapidly …”. The editor was driving towards the point that it is cliché. Everyone these days is
writing articles stating how much has changed recently in writing code and building software. She goes on
to add please don’t write about AI creating an impression that it is a growing trend. To be frank she is right.
It is not a growing trend it is already in adoption and soon it will enter into the value-mining phase. But this
dispatch is not about AI.
If you were vigilant, we got our way with that sentence. Even though our editor recommended against it.
Not to be bad to our editor, she signed off this afore paragraph as she loved the way we got around her
objection. It is enough of gloating and let us get to what we were to deliver to you.
We are here to touch upon a sentiment. The sentiment of expressing high emotions with few simple ASCII
characters. asdf happens to be one such common expression in the social lingua franca. The reasoning
behind calling it is due to the way we would thump the table if we want to express our extreme emotions in
the heat of a discussion. Instead of a table in this virtual social world, it is with the keyboard. We truly loved
to learn such an expression that reflects one’s high emotions is called key smashing. Thus, the literal asdf
is a keysmash. It is more than that. It is also a tool that reflects the high emotions of the developers who
build systems along with architects who have in their sane minds decided to use the right language for the
right purpose. With such a polyglot nature of building software managing versions of the CLI and tools that
aid in building the software becomes an eminent need.
asdf is a tool that fulfils the need to manage versions of all the tools that are required by the developers to
build software. Managers like npm, nuget, maven, and pip help in doing so for dependencies in the
respective languages. For a polyglot build environment this asdf keysmash tool as we call it dearly; is the
solution to keep the developers sane and not engage in a civil war with architects and testers inside the
organisation.
Warning for want to be developers and Windows enthusiasts; asdf is not for you. It is not a GUI tool. It rides
on the strengths of bash scripts. Remember we said want to be developers to emphasise the starters. If
you are an advanced user of Windows, then you have a couple of arrows in your quiver. One is of course
installing Cygwin and another is a more modern way i.e., Widows Subsystem Linux (WSL). It works great
with Unix and Linux machines. Yes, you can have it if you are developing on Mac machines. You can
imagine asdf as a VM which with the aid of what asdf knows as a plugin helps you manage tools of many
programming languages. Plugin is a prominent term that you will encounter in this tiny yet powerful tool.
Another term that you must know for better in this context is Shim. The word is used in the regular context
where it is synonymous with Polyfills from the world of HTML5 and Javascript. Shim is something that you
do not create but are supplied as part of the plugin. The shim intercepts the call to any plugin’s command
let us say npm install kind of command and targets the right version of the installed plugin.
Plugin
It is a URL to a git repository. That has scripts which asdf expects. These scripts help asdf manage
versions and do other run-of-the-mill activities you would expect of such a tool.
Installation
There is well-articulated instruction to install the tool. The bottom line is you clone the asdf remote
repository on your machine and add the script file location to the environment variable. This helps you run
the script from anywhere. Ideally, you will want to do that, isn’t it? Quick list of all the instructions assuming
you are on Ubuntuuntu Linux distribution
# git clone https://github.com/asdf-vm/asdf.git ~/.asdf
# echo “. “$HOME /.asdf/asdf.sh”” >> ~/.bashrc
# echo “. “$HOME/.asdf/completions/asdf.bash”” >> ~/.bashrc
Once done with this you get into finding the plugins for programming languages you want. There is a list of
official plugins for the Elixir, Erlang, Node.js, and Ruby languages. It does not end there. Community-
supported plugins are vaster. There, is a GitHub repository dedicated just to listing all such community-
supported plugins.
With these, you can start with a low threshold to entry of setting up your development environment.
Usage
# asdf plugin add python https://github.com/asdf-community/asdf-python.git
# adf plugin add nodejs https://github.com/asdf-vm/asdf-nodejs.git
By executing the above lines, you are indicating that your project will use Python and NodeJS. Next, you
will get the versions you want to use.
# asdf install python
# asdf install nodejs 14.2
Here you are installing the latest version of Python but a specific version for NodeJS. This action will create
a file named .tool-versions in the directory where you executed the above command. Like package.json
which contains the list of dependencies, this file contains the version locks of the CLI you use in your
projects. Once this is done it is all you got to do.
The real-world challenge comes if you have to use say the latest version of NodeJS in a submodule of the
project. You have to change your directory to that submodule and do the same action as above.
# cd cool-new-submodule
# asdf install nodejs latest
Keep in mind you have 1 version of Python and 2 versions of NodeJS when looked at by standing in the
project’s root directory. The magic that solves your painful problem of language-specific virtual environment
management is the shims implemented by those plugins. So, when you run the command at the project’s
root directory the system will be running the command against the 14.2 version of NodeJS.
npm install nextjs
Whereas if you run the same command standing the in directory cool-new-submodule you will be running
that command on the latest version of NodeJS. The next level of this magic comes next. The next
command will have the same effect irrespective of whether you run the command from the project’s root or
submodule directory.
# pip install numpy ## @ project’s root directory uses the latest version of Python
# pip install pandas ## @ cool-new-submodule uses the same version of Python
The above is an example of how asdf resolves the right version of the package based on the scope of the
tool version. For NodeJS there are two scopes one for the project directory and a more specific one for the
cool-new-submodule directory. Whereas for Python there is only one scope. These scopes can be also set
across the machine or in other words global. For some reason say your architects do you to use different
versions for NodeJS within a project they could supply you an environment initialisation script which runs
the following commands –
# asdf local nodejs system
Custom plugin
If you do not find what you need in the community or the official plugin for asdf you can create one. You
need to clone a template repository. The asdf-vm/asdf-plugin-template repository when cloned to a folder
please name it suitable to the language/tool you are targeting. From the object-oriented world, this
repository is like an interface. You are then to implement the interface methods which translate to folders in
that repository.
You need to keep in mind that you do not use any of the asdf commands in the implementation and you do
not use any of the platform-specific commands that potentially cannot be run in another distribution of Linux
or MacOS.