3 ms·

It's less about package versions (which are indeed versioned on a per-project basis in sane ecosystems - python being a notable exception) and more about versio

It's less about package versions (which are indeed versioned on a per-project basis in sane ecosystems - python being a notable exception) and more about versions of the language toolchain itself. e.g. you might want one project on Java 17 and another on Java 8. These tools allow you to seamlessly switch between those.

twblalock 5y ago
Java tooling already provided that and it’s trivial to install multiple JDK versions on a system. I probably have 4. Most IDEs have a dropdown to pick the one you want, there are CLI tools for it too, and overall it’s about as complex as a $PATH variable. It’s also possible to install multiple versions of Python on a system. The dependency management is the real problem — having more than one version of a runtime is not the hard part.
- nicoburns 5y ago
  If Java provides good first-party support for this then it may not make sense to use asdf for Java. Rust is similar in that rustup is first-party the recommended tool to install Rust with. I don't bother with asdf for Rust. Other ecosystems like python/ruby/javascript don't provide this as a first party tool meaning there are lot's of 3rd party alternatives. For these ecosystems asdf is nice in that it allows you to use one tool across all the ecosystems. > The dependency management is the real problem I'm not sure how this works in Java, but in many ecosystems like JavaScript and Rust dependency management isn't an issue at all. Installing a package defaults to a local install and even things like dependencies transitively depending on different versions of the same package are supported out the box and just work.
smoe 5y ago
What do you refer to by saying Python is an exception? I haven't used anything but different language and package versions on a per-project basis since around 2007. I had some project with deployments on client servers where their sysadmin insisted on having everything installed as os packages, but this at least from my perspective hasn't been the norm for quite a while now. Not to say that I like the Python package management story.
- nicoburns 5y ago
  Commonly used tools like virtualenv allow you to do this, but it's not the default in the python ecosystem: `pip install foo` will install foo globally. In most other ecosystems the equivalent command (e.g. npm install foo) defaults to a local install with no effort on your part.

twblalock 5y ago

Java tooling already provided that and it’s trivial to install multiple JDK versions on a system. I probably have 4. Most IDEs have a dropdown to pick the one you want, there are CLI tools for it too, and overall it’s about as complex as a $PATH variable. It’s also possible to install multiple versions of Python on a system. The dependency management is the real problem — having more than one version of a runtime is not the hard part.

nicoburns 5y ago
If Java provides good first-party support for this then it may not make sense to use asdf for Java. Rust is similar in that rustup is first-party the recommended tool to install Rust with. I don't bother with asdf for Rust. Other ecosystems like python/ruby/javascript don't provide this as a first party tool meaning there are lot's of 3rd party alternatives. For these ecosystems asdf is nice in that it allows you to use one tool across all the ecosystems. > The dependency management is the real problem I'm not sure how this works in Java, but in many ecosystems like JavaScript and Rust dependency management isn't an issue at all. Installing a package defaults to a local install and even things like dependencies transitively depending on different versions of the same package are supported out the box and just work.

smoe 5y ago

What do you refer to by saying Python is an exception? I haven't used anything but different language and package versions on a per-project basis since around 2007. I had some project with deployments on client servers where their sysadmin insisted on having everything installed as os packages, but this at least from my perspective hasn't been the norm for quite a while now. Not to say that I like the Python package management story.

nicoburns 5y ago
Commonly used tools like virtualenv allow you to do this, but it's not the default in the python ecosystem: `pip install foo` will install foo globally. In most other ecosystems the equivalent command (e.g. npm install foo) defaults to a local install with no effort on your part.