Asdf: [proposal] Update fileformat for `.tool-versions`

Created on 18 Dec 2016  路  6Comments  路  Source: asdf-vm/asdf

First, thanks for this project! It's really great to have all of my version
managing in just one tool! :+1:

However, I think that the format of the .tool-versions file is a little too
simple, and changing to another format could allow for some pretty useful
features!

These are some features I would like implemented into asdf, but I think it
would be difficult to do without updating the .tool-versions file format.

Specifiy which repository to use for each language

When only adding a .tool-versions to the home directory and call
asdf install, there's no way to know which plugin to use to install the
languages specified in the .tool-versions file. By specifying this in the
file, the asdf tool could fetch the correct plugin if not already present
on the system.

Running commands after installing a new version of a language

Whenever you install a new version of a language, there might be some things
you want to install globally for that versions (examples might be bundler for
ruby or webpack for nodejs).

What do you folks think about this? Do you think these would be useful features?
Should I create separate issues for these feature requests? Is this out
of scope for the asdf project?

Thanks!

proposal

Most helpful comment

I'd vote for keeping it as simple as we can, both the .tools-version format and the install semantics, IMHO asdf should not do anything other than what it was asked to do (install the tool version), for me, installing things like webpack on node is something some people would not actually need. Also keep in mind that the tools-version file should be simple to be easily read with a simple grep on most unix* platforms (the more we complicate things, the more fancier asdf would get just to read that file, keeping it simple would help making asdf run on most platforms without problems).

All 6 comments

I'd vote for keeping it as simple as we can, both the .tools-version format and the install semantics, IMHO asdf should not do anything other than what it was asked to do (install the tool version), for me, installing things like webpack on node is something some people would not actually need. Also keep in mind that the tools-version file should be simple to be easily read with a simple grep on most unix* platforms (the more we complicate things, the more fancier asdf would get just to read that file, keeping it simple would help making asdf run on most platforms without problems).

One option regarding Specifiy which repository to use for each language could be, if you run:

$ asdf install foolang
No such plugin

Instead of just showing No such plugin was found, we could grep the README.md file for foolang and if we have a plugin listed there, we could show a friendly message for the user to install the plugin.

$ asdf install foolang
No such plugin

Maybe you need to add the foolang plugin:

   asdf plugin-add foolang http://github.com/somerepo/asdf-foolang.git

I am against making .tools-version more complicated, but there are plenty of approaches we could take to improve things.

Showing a hint as @vic proposed is I think a good idea. I would however not do anything automatically.

To allow to install things after installing a plugin, we could have a hooks directory.
I can think of something like this:

|---- pre-install
|---- post-install
|---- ruby
      |--- pre-install
      |--- post-install

and we could just source the files if they exist.

I am not very sure if it is really worth or not though.
What do you think?

hm.. giving it a second thought, I guess I can see your point now, if I create a file ~/.asdf/hooks/ruby/post-install and then use the ruby plugin to install a new version, asdf will just source the post-install script I created just after ruby is available, for example to install bundler or something.

In that case I'd be +1 on having hooks, but they should be explicitly created by the user :)

dont know what could be the use case for the non-plugin specific hooks/post-install

There doesn't seem to be much benefit to hooks if the user must create them manually. It's easier to just run the post install stuff (bundler or whatever) after install than to setup a hook prior to the install.

This is something that could be easily solved outside of asdf so I'm not sure implementing it in asdf is necessarily a good idea. For example, a user could create a simple bash script like this (pseudo code, I haven't tested this):

``` ruby_install.sh

!/bin/bash

script to install ruby and run bundler

version=$1

if asdf install ruby $version; then
# Post-hook commands to be run after successful install
bundle install
else
echo "asdf failed to install ruby $version"
fi
```

Then the user can just use this script to install ruby and any custom commands they have specified will be executed: ruby_install.sh 2.0.0.

@Stratus3D That's how I'm using it at the moment. Thought it would be a useful for the asdf tool so wanted to check with you folks about the idea. :)

Should we close this issue?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jthegedus picture jthegedus  路  3Comments

romenigld picture romenigld  路  4Comments

Quintasan picture Quintasan  路  5Comments

pachun picture pachun  路  3Comments

jamesstidard picture jamesstidard  路  4Comments