What does HackerNews think of asdf?

Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more

Language: Shell

#1 in Elixir
#1 in Node.js
#2 in Ruby
#5 in Shell
That's what I would suggest as well. WSL2 and use asdf[1] to manage the erlang/elixir versions.

You could also use containers pretty easily as well with docker or podman for windows and the official Elixir images[2].

[1]: https://github.com/asdf-vm/asdf

[2]: https://hub.docker.com/_/elixir

You may consider using asdf or some other Python version manager to get a newer (or older) Python

https://github.com/asdf-vm/asdf

Not a generic package manager, but it's probably worth calling out asdf as the generic version manager[0] (maybe you're already aware of it, but it's a generic replacement for nvm, rvm, virtualenv, *vm, which supports any language based on plugins.)

Again, maybe you're already aware of it, but I think it's a nice example of genericising a concern common to many languages which sounds similar to what you're asking for (albeit unfortunately in a slightly different space).

[0] https://github.com/asdf-vm/asdf

What benefit would joining your cult bestow upon me that brew does not already?

My brew list is intentionally very short and my faffing about desire is limited.

Generally I use brew to pull in asdf (https://github.com/asdf-vm/asdf) to install programming languages/tooling, it works flawlessly.

I use Pipx (https://github.com/pypa/pipx) to install python thingies (such as yt-dlp) as a cli.

Go and Rust handle binaries in their languages beautifully and without issues.

It's basically the same as https://github.com/asdf-vm/asdf than, plus lisp for config?
I thought that this was going to be about ASDF (Another System Definition Facility; a module manager for Common Lisp): https://asdf.common-lisp.dev/

Turns out that it’s a version manager (now there’s another overloading: ‘VM’ to mean ‘version manager’ vice ‘virtual machine’): https://github.com/asdf-vm/asdf

asdf works as a universal tool for any cli app i.e. python, terraform, ruby, golang, etc

https://github.com/asdf-vm/asdf

    asdf plugin add python

    asdf install python 3.9.1

    asdf global python 3.9.1

    asdf local python 3.9.1
This might show my ignorance, but can Nix replace something like asdf (https://github.com/asdf-vm/asdf)?
I thought it's a joke post after that, but apparently this is a real project: https://github.com/asdf-vm/asdf
I've recently discovered `asdf` (https://github.com/asdf-vm/asdf). It's not as technically clever as nix, but it does allow you to manage version of most language toolchains with one tool.
To people as lost about this as I was: ASDF here is the common lisp build system [1], not the tooling version manager [2]. Entirely my fault I was confused, tbh.

1: https://asdf.common-lisp.dev

2: https://github.com/asdf-vm/asdf

For anything versioned, I use asdf: https://github.com/asdf-vm/asdf

It's straightforward enough that the software devs I work with consider it "painless" to use.

asdf describes itself as "asdf is a CLI tool that can manage multiple language runtime versions on a per-project basis. It is like gvm, nvm, rbenv & pyenv (and more) all in one!"

please, instead of creating something that's language/tool specific, work on asdf-vm[0]. We all benefit if we don't have to remember which version manager to use for which tool/language/whatever.

[0]: https://github.com/asdf-vm/asdf

Instead of one different tool for each runtime or ecosystem, I prefer to use ASDF. https://github.com/asdf-vm/asdf
> is there a version manager I should be using?

> I am familiar with nvm and pyenv for managing Node and Python versions, respectively, however the tutorial I was following did not mention any Ruby version manager. I took to the internet and found the highly popular, rbenv.

If you want "just" a version manager for ruby, I'd go with rbenv. But if you use, say, node and python too - I'd go with asdf:

https://github.com/asdf-vm/asdf

https://github.com/asdf-vm/asdf-ruby

Keeps the stampede of VMs out of your bashrc.

I've been using ASDF (https://github.com/asdf-vm/asdf) for a while now to manage each of the language (and sometimes build tool) versions for a folder/repo in a consistent manner. I'd definitely recommend taking a look at it.
And `pyenv` [1], for Python.

I came into `nodenv` after being a regular user of `pyenv` for a while. Started with `nvm`, but wished for something more pyenv-like.

There is also `asdf` [2], which seems even more generic. On paper it looks interesting, but I haven't found a solid reason to switch out of `pyenv` and `nodenv`.

Has anyone tried `pyenv` and/or `nodenv` and switched to `asdf`?

[1] https://github.com/pyenv/pyenv [2] https://github.com/asdf-vm/asdf

Virtualenv lets you use only a Python interpreter that's already installed on your system. Usually the choice is between the latest v2 and v3 interpreter, at least on Debian derivatives. Every virtualenv is autoupgraded each time the OS upgrades its Pythons.

If you want to use multiple versions of Python and pin them, you should use something like asdf [1] and its Python plugin [2]. It's a version manager with support for many languages and more. I used it for Elixir, Node, PHP, Ruby and even PostgreSQL (I need different database versions in different projects.) I never used it for Python because I'm OK with being on the latest version so far.

With asdf I would expect to do something like this

  asdf install python 3.7.5
  mkdir my375project
  cd my375project
  asdf local python 3.7.5 # pick the version to use here
  python3 -m venv py375 --python=~/.asdf/installs/python/3.7.5/bin/python
  ~/.virtualenvs/py375/bin/activate
This virtualenv is going to stay on 3.7.5 forever.

[1] https://github.com/asdf-vm/asdf

[2] https://github.com/danhper/asdf-python

> replace brew python with pyenv.

replace pyenv with asdf [0]. asdf is like pyenv, but it works for all major programming languages.

[0] https://github.com/asdf-vm/asdf

These days I use `asdf` for everything--think of it as a pyenv/rbenv/nvm for Python, Ruby, Java, NodeJS, and a ton of other stuff. Through it I create virtualenvs, each targeting a particular version of Python.

https://github.com/asdf-vm/asdf

This looks very nice! I wonder if it might be easy(ish) to wrap it as a plug-in for asdf? There's already an opam/ocaml plug-in - but from comments here it sounds like it might be possible to write a wrapper similar to the ruby plug-in that re-uses a lot of the tooling for rbenv/build. (as does the rust plug-in, and others)

https://github.com/asdf-vm/asdf

No language has this down, but there's an environment manager (pip, rustup, rbenv..) that try to do all, and avoid the need to handle more than one "magic" session in your bashrc(etc): "asdf":

https://github.com/asdf-vm/asdf

Now, a few new languages do come with pretty decent "virtual env" thingy-s , but most stumble for a few years.

So far (past year) I've been pretty happy with asdf. Mostly use it for ruby and node - but also rust and golang, lisp, Java and ocaml (mostly as a "consumer" of various cli tools, and/or toy projects.

I really appreciate the people who include descriptions and links for their list. My list has been pruned to avoid duplication (though perhaps knowing what's popular is a good metric too).

asdf: https://github.com/asdf-vm/asdf - installs many different programming languages and supports installing different versions concurrently. I use it for go installs since distribution updates aren't usually fast enough.

solaar: https://github.com/pwr/Solaar - handles configuring a logitech unifying receiver in Linux. Not really something you'd use multiple times, but am thankful it exists (also has a GUI too I believe).

Polyglots might also be interested in asdf (https://github.com/asdf-vm/asdf). It's like Pyenv but supports various languages via a plugin system (eg. https://github.com/danhper/asdf-python).
I've recently revisited asdf, and based on some testing, started moving my various compilers/interpreters to that. It's a "general" version manager - that works like rbenv for "all" languages.

I'm not sure if I'd use it for deployment - but for development it's quite versatile.

https://github.com/asdf-vm/asdf

Try a language manager. One I know to work on MacOS is asdf

https://github.com/asdf-vm/asdf

Then, there is something wrong with either brew or MacOS or both because we can install both Python 2 and 3 in parallel on any Linux with the system package manager.

I use asdf [0] for this. It lets you install and run different versions of any language. I keep a sensible global default if I'm just experimenting with stuff, but for any serious project I'd create a .tool-versions file in its root to specify the exact language version I'm developing and deploying against.

[0] https://github.com/asdf-vm/asdf

I use asdf [0] for managing the multiple versions of different programming languages. Here's the golang [1] plugin.

You need to be able to make some assumptions about your environment in order to implement tools like these. All you're doing is specifying the context in which certain commands within your workspace will run.

A common pattern I've seen with some npm packages is to have the globally installed executable delegate to the project-specific version. This is a nice solution, but it's unrealistic to rewrite lots of projects to use this approach.

IMO, text-based interfaces are still too limiting though. I want to interact with GUI apps programmatically as well! On macOS you can achieve a little bit of that with AppleScript (or with JavaScript in newer versions), but it's still not frictionless.

[0] https://github.com/asdf-vm/asdf

[1] https://github.com/kennyp/asdf-golang

For Windows, I'd like to point to http://scoop.sh as mentioned here:

https://news.ycombinator.com/item?id=17019197

It's a bit like a mix of (x)stow and apt for Windows. Or the good parts of arch aur with binary distribution.

Should probably also mention that I'm experimenting with asdf as a version manager - to avoid a long list of setup in bashrc to adjust paths to various interpreters. It follows a lot of best practices that various dedicated version managers seem to pick up eventually:

https://github.com/asdf-vm/asdf

I'm on 16.04 and I have no problems with that. I use the repositories of the developers, so I get the latest versions. I use Canonical's repositories for the OS and the software I don't really care much about. I had no problems with this approach (LibreOffice, PostgreSQL, etc). I occasionally run some software in a docker container to get the latest version, or to run multiple versions of the same server application (example: I've got two Redis for two different projects). Asdf [1] can manage multiple PostgreSQL versions (and several languages).

The real advantage of staying on a LTS has been no big updates and no changes in the GUI. I'm on Gnome Flashback which I tweaked to be as closed as possible to Gnome 2. It seems that Gnome Shell eventually got enough extensions to also make it look like Gnome 2. I'll give it a try again after those memory leaks will go away. I can probably stick to 16.04 for another year before developers start skipping it in their builds.

Edit: I checked and I have git 2.17.0, which is the latest version. I keep it up to date with ppa.launchpad.net/git-core/ppa/ubuntu

[1] https://github.com/asdf-vm/asdf

I've stopped using any other virtual env managers than asdf[0]- it has one simple API for pretty much everything.

You can define a .tools-versions file in the root of your project, which lets you install the correct versions with a simple `asdf install`. We even use this in CI for zero-config language version upgrades.

[0]: https://github.com/asdf-vm/asdf

On the subject of version managers for multiple programming languages, people might be interested in checking out asdf [0]. nvm was my favorite tool for handling multiple node versions, but I've found asdf suits my needs a bit better.

I'd still reach for nvm for deploying to a server. To the best of my knowledge, the code is portable across all UNIX-y OSs.

On the other hand, asdf supports multiple languages, so I was able to kill off rvm too! It also has considerably better performance (specifically, startup speed).

EDIT: As to the discussion regarding Ayo.js... I've never interacted with Rod personally, but having read a few hundred of his miscellaneous responses on GitHub, he has never struck me as someone unreasonable. His response to the criticisms being raised seem very reasonable as well. If anything, I now feel like I have a bit more trust on node team.

Based on my highly limited outsider's perspective, trying to kick him seems overly harsh. If people believe he's doing things poorly, an avenue should be created through which constructive criticism and feedback can be provided. We're all human, we make mistakes, and we sometimes don't understand each facet of problems we encounter.

[0] https://github.com/asdf-vm/asdf

asdf [0] is a great alternative to nvm. The best part is that it supports multiple languages and it's fast. I use the plugins for elixir, erlang, nodejs, and ruby.

Many CLI tools are missing completions, but I think it's slowly getting better over time. The pros outweigh the cons for me.

[0] https://github.com/asdf-vm/asdf

[1] https://github.com/fisherman/fisherman

A couple of months ago I stoped using rvm, kerl, exenv, nvm and started using asdf - "Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more".

I've been pretty satisfied with it, and haven't had a single problem with it yet - it just works (™).

I recommend trying it out, relevant links:

https://github.com/asdf-vm/asdf

https://github.com/asdf-vm/asdf-erlang

Homebrew sometimes takes a while to get new erlang releases available. I seem to recall a release about a year ago that took over a month to become available. Something about other apps in homebrew that use erlang having to update before the homebrew erlang could be released, or something like that, I don't recall the details.

At any rate I've been using asdf https://github.com/asdf-vm/asdf to manage my erlang and elixir installs on a per project basis for a while now and it has been working well for me.

You just install the new Erlang VM, install Elixir 1.3, and that's it! Elixir 1.3 is compatible with Erlang 19, and will by default use the Erlang installation available on the path, so nothing to do in particular.

If you want an easy way to install both, you can check asdf [1].

[1]: https://github.com/asdf-vm/asdf

I'm using asdf - it has the added advantage of being able to manage ruby, erlang, node, and more :) https://github.com/asdf-vm/asdf