I've used asdf for years, but recently switched to <a href="https://github.com/jdx/mise">https://github.com/jdx/mise</a>
It's a drop-in replacement for asdf, but I prefer some of the nice features it has to offer.<p>See: <a href="https://mise.jdx.dev/dev-tools/comparison-to-asdf.html" rel="nofollow">https://mise.jdx.dev/dev-tools/comparison-to-asdf.html</a>
Wait, not only is it called asdf leading to confusion, it literally is also a package manager of sorts just like the original asdf???<p>I just tried googling it having not really used CL in a while, and apparently it was seo'd to the top of google results too?
Having been down this path - asdf didn’t go far enough in creating reproducible/sealed environments, the quality of the plugins per language varied dramatically, shims made a lot of assumptions about how tools will be used, and you can expect to throw asdf away the moment you need to deploy and then have to build something else.<p>I don’t like Nix but I haven’t found anything else that scales along those critical requirements. I don’t think it’s a good idea to simply replace rbenv/nvm/etc with asdf-ruby-plugin and so on - unless your software isn’t intended to leave your development machine?<p>(Docker for me fails in the opposite direction - fairly miserable to develop with but trivial to deploy.)
Sounds like nix using devenv[1] also would solve this problem.<p>[1] <a href="https://devenv.sh/" rel="nofollow">https://devenv.sh/</a>
Out of curiosity, how many dev environments do folks use? Is this for reproducible environments shared by members of a team or company?<p>For a single user with one development machine, simply having say a time-machine backup could be sufficient. I haven't had challenges for personal projects where details mattered. e.g. a Maven pom.xml, or Go modules/packages was sufficient for my needs.<p>Historically I'd only cared about automating the spec of production environments. Why would I want/need this?<p>I now recollect once being contacted out of the blue as being a person who might be able diagnose/solve an issue at a company I'd never worked with. They had two dev machines and only one of them could produce a working program. Their team couldn't figure it out. I gave them a rate and arrived on-site. It was a Visual Basic 6 program, so I just took two half days going through every EXE & DLL related to Windows and VB, eventually finding the difference. Tedious but not rocket science. Is it to avoid these cases?<p><i>Edit: We have project onboarding instructions where I work. I suppose it could be useful for making those. I don't make them but could appreciate if they used a standard rather than bespoke scheme.</i>
I've had nothing but problems with asdf and nodejs and globally installed tools like yarn reporting "Cannot find node". Perhaps global tools cannot be compatible I don't know; asdf reshim doesn't often fix it.
I loved asdf but since moving to immutable fedora I've started loving distrobox more.<p>By giving each box it's own home folder vscode in each has only the extensions for that language. E.g I don't have any python extensions in my nodejs box.<p>Been working like this for a couple of weeks now and it's pretty good.<p>If I end up breaking a box I can simply delete it and start over.
I created <a href="https://github.com/jrz/container-shell">https://github.com/jrz/container-shell</a> to add a layer of security / isolation in addition to tools like asdf.
I had to install a couple of alternative python versions on my dev machine at work and found it was easiest for me to just build from source and `make altinstall` with a custom prefix set. From there I just always work in virtual environments. This doesn't seem to have created any major problems for me, so something like asdf doesn't feel necessary. Is there something serious that I've missed or is this just a case of different preferred workflows?
I’m liking pkgx over asdf as it can activate project tooling upon cd’ing into a project folder.<p><a href="https://pkgx.sh" rel="nofollow">https://pkgx.sh</a>
Thanks to OP for mentioning vfox (version-fox) in the article. vfox as a project just five months ago, there is still a lot to do, welcome to those who use Windows as a development environment, to participate in the construction of the vfox plug-in ecosystem.<p><a href="https://github.com/version-fox/vfox">https://github.com/version-fox/vfox</a>
I like x-cmd because its package system is written in more compatible posix-shell and awk, resulting in much smaller loading and startup overhead. Additionally, x-cmd integrates with asdf and provides AI support, along with over 200 modules for various command enhancements<p>See:<a href="https://x-cmd.com/pkg/" rel="nofollow">https://x-cmd.com/pkg/</a>
Is it just me that never even wants to get to the problems that asdf attempts to solve?<p>That example in the article of managing multiple python 2.7 versions sounds like a horror story.
Because of the insanity of python versions, paths, wheels etc and tiredness of spending time getting poetry install to work for project X due to also needing a full rust and c++ toolchain for some dependency etc..<p>.. I run everything for a project in a container. Each project then matches perfectly the container actually used in production, so if it works there, it also works on my machine. I just volume mount the project folder into the container so I can't edit files from my IDE, and then pycharm has ok support for remote interpreters.
Fantastic tool, it also replaces direnv / .env requirements as it will automatically load variables you set in your .mise.toml file in the [env] section, except that it's much faster than direnv.
Was it just bad luck that this got named the same thing as the main Common Lisp package/build manager? (Also not helped that "package" means something very different in CL)
The existence of asdf is a byproduct of a larger problem: tooling for certain popular (Python) and not so popular (Ruby) programming languages is simply inadequate.