Is it just me that never even wants to get to the problems that asdf attempts to solve?
That example in the article of managing multiple python 2.7 versions sounds like a horror story.
That example in the article of managing multiple python 2.7 versions sounds like a horror story.
> Is it just me that never even wants to get to the problems that asdf attempts to solve?
You aren't alone, the scenario isn't ideal. However, brew's Python installation on MacOS as are Debian's and Ubuntu's are _extremely_ brittle. You are one cask, formulae or apt package away from needing to do a weekend-long spelunking session or a full blown system re-install if you have deadlines.
PyEnv is a pain to set up, and maintain, which is what I used in the years before as well as after Python 2 was deprecated and projects started slowly migrating to newer python versions.
> That example in the article of managing multiple python 2.7 versions sounds like a horror story.
It is a horror story, but is very common.
Have you tried to install and maintain Java, Kotlin and Graddle installations for a given project although your machine is not primarily a Java, Kotlin, Graddle box? That is a real nightmare, not so much with asdf.vm.
I've been using python installed using homebrew and haven't found any issues. In homebrew you can install a specific python version like python@3.11 and using venvs avoids most of the issue (I think you can't install packages outside of a venv in python 3.12 or higher).
It will manage the JDK for you. Usage is basically this:
# Install a JDK, that version is now default
sdk install java <version>
# Another one, it asks if you want to change the default
sdk install java <another-version>
# List available and installed versions
sdk list java
# Change which one you're using in this shell
sdk use java <version>
You can also manage Gradle/Maven installations with SDKMAN, but that's not necessary, usually, because most JVM projects include a "wrapper" script which downloads the needed Maven/Gradle version for you.
This works regardless of whether your project also needs Kotlin/Groovy etc. as those are just managed by Gradle/Maven (the only exception I can think of is if you use Kotlin Multiplatform as that will depend on the platform dependencies as well).
So once you know SDKMAN, you can manage any JVM-based project with just this:
sdk use java <jdk-version-used-by-project>
./gradlew build # or ./mvnw package
Sure. But you might need node for some front end build tool, or a language server for sql. Then you can use two version managers, or just asdf.