I've used asdf for years, but recently switched to https://github.com/jdx/mise
It's a drop-in replacement for asdf, but I prefer some of the nice features it has to offer.
No disrespect to mise but this what’s so frustrating about the industry. Just as one starts getting popular, some people move on to something “better”.
Mise/rtx doesn't cut it for us. It's approach is shell-based, so if your programs launch sub-processes, mise won't be applied. So for example Node scripts running in version 18 might npm run a process, which gets launched with the system node.js version.
Where-as asdf creates shims that go into the PATH. That way any processes launching processes using normal env rules have asdf applied.
Mise looks well built & is very fast. But it's jaw dropping to me that it's coverage is so drastically lower than asdf.
I still prefer asdf. It does the job just fine. Direnv has its own stdlib, which sometimes I find useful, and make is something I have to install anyway.
I recently started using https://github.com/prefix-dev/pixi for Python projects. I really love it so far, but this tool looks a bit more mature, which makes sense considering pixi is relatively new.
One of my pet peeves with tooling these days is the completely random naming. Literally no effort made, whatsoever, to come up with something vaguely descriptive. Neovim plugins are the worst for this. They're comically badly named.
I raised this complaint before and learned that most people using the "new" one have never even heard of Common Lisp, and certainly not of its own "asdf" system.
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.
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?
(Docker for me fails in the opposite direction - fairly miserable to develop with but trivial to deploy.)
People complain a lot about NPM, but I find it solves all these problems reasonably nicely. It's pretty easy to use in development and it's easy to deploy (either using node_modules in production, or bundling, both approaches work).
Of course it only works if your codebase and tools are all JS-based!
Having worked recently on a project that was mostly TypeScript with some Python, the TS bits were mostly straightforward but the Python was a hassle in both dev and production (I used venv). I can see that asdf might have been handy for development but if it didn't have a good deployment workflow that wouldn't have helped.
> I don’t think it’s a good idea to simply replace rbenv/nvm/etc with asdf-ruby-plugin and so on
ASDF generally doesn't reinvent version management, but wrap and re-use ruby-build, node-build etc.
It fails if your single project is a legacy monster needing four versions of node, two pythons and a handful of javas - but that's not a common use case.
More commonly you have multiple projects, each with a single version of node, python and java. For deployment you only need one of each - it's in development you need five of each when switching between projects.
- steep steep learning curve, so your team is split between those who can understand it and those who have to blindly follow checklists and ask for help when something breaks
Out of curiosity, how many dev environments do folks use? Is this for reproducible environments shared by members of a team or company?
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.
Historically I'd only cared about automating the spec of production environments. Why would I want/need this?
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?
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.
always, golang is overly opinionated regarding where modules and binaries are stored. I don't like that and I've blown my local development environment into pieces because of that (looking at you GRPC, yikes)
But also, imagine that you, like me, need to test Python, Java+Kotlin+Gradle and NodeJS+Angular stuff. Do you really want to install _all that_ natively ? Just for a couple of merge reviews, and even if not, do you _really_ want to install all that natively ? The answer is always, IMHO, a resounding and clear no.
> 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?
For example, but also much worst, as mentioned in the OP it's to prevent the very real possibility of crippling your OS's language runtimes and also to stay productive.
I routinely work in Ruby, Python, Javascript, Java, Go, and Rust. The thing that drives me to use asdf is that without such a tool, every language needs a different version or installation manager and they all work slightly differently. It's a hassle to remember 6 different sets of commands for how to install a new version, check which version is active, switch to a different version, and to remember the slightly different quirks that each language's tool has. With asdf, they all work exactly the same. Granted that with Rust and Go it's usually less necessary to keep older versions around, but you definitely need it for Python and Ruby. Better to have all the languages work the same even if it's a bit more complex than needed for some.
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.
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.
Been working like this for a couple of weeks now and it's pretty good.
If I end up breaking a box I can simply delete it and start over.
Also moved to immutable Fedora, and had to move away from doing `pacman -S go python node` on the host for all my dev tools. Tried to keep doing that in a distrobox, but it kept breaking due to me not updating it. Then I started building my own toolbox container with all I need in it for local consumption from GHCR, and that works a bit better, but recreating it is still annoying. I ended up using Devbox as a Nix wrapper for many new projects, but those could all use asdf/mise too, and I might consider switching some over.
One project of mine, though, requires a shareable / pseudo-reproducible dev environment. Devbox didn't cut it, and mise especially couldn't have, since it requires some system deps. I went with a Nix Flake, which worked fine, but also started building a special distrobox image for the project, this time udimg Fedora as a base, as I perceived it as more stable. Using it too distrobox still had some issues, but I managed to make a shim/helper that runs `pnpm` from inside the container and that works pretty perfectly. Might be a bit worse on the performance side, though. We'll see.
Nice, I've been thinking about building something similar. However, I'd still like to use my shell configuration/dotfiles inside the container (and I'd like my team mates to be able to do the same) and, so far, I haven't really found a good solution for that.
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 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.
How do you update the list of installed python versions?
Generally asdf shines when you need more than one system installed - say a html or SQL language server that depends on node in addition to python for your main app.
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.
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
OP here, although I hoped I took an example that was relatable, it seems it wasn't as relatable as I expected.
> 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.
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..
.. 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.
The sheer amount of wasted time is hard to comprehend. How many man-hounrs or rather man-centuries have we spent trying to make python fast and trying to install it?. We just keep on polishing that turd.
Yeah. IMO, you don’t need to go very far into OS-level dependencies before it just makes more sense to use Docker. asdf et al can try to smooth the experience out all they want, and they certainly make things better, but unless your developer machines are REALLY standardised, it’s really building a castle on sand.
Whish there were some CLI to speed up this process actually. Just cd:ing into a folder should pull everything down for you to run iex/irb/node/etc as if it was native but running through the container.
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.
thedookmaster|1 year ago
See: https://mise.jdx.dev/dev-tools/comparison-to-asdf.html
hk1337|1 year ago
jauntywundrkind|1 year ago
Where-as asdf creates shims that go into the PATH. That way any processes launching processes using normal env rules have asdf applied.
Mise looks well built & is very fast. But it's jaw dropping to me that it's coverage is so drastically lower than asdf.
oakesm9|1 year ago
The main differences are better UX with simpler commands and it not using shims, which means much better performance
roylez|1 year ago
quickslowdown|1 year ago
abrookewood|1 year ago
cholindo|1 year ago
noobermin|1 year ago
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?
000ooo000|1 year ago
brabel|1 year ago
phinnaeus|1 year ago
lexlash|1 year ago
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?
(Docker for me fails in the opposite direction - fairly miserable to develop with but trivial to deploy.)
iainmerrick|1 year ago
Of course it only works if your codebase and tools are all JS-based!
Having worked recently on a project that was mostly TypeScript with some Python, the TS bits were mostly straightforward but the Python was a hassle in both dev and production (I used venv). I can see that asdf might have been handy for development but if it didn't have a good deployment workflow that wouldn't have helped.
e12e|1 year ago
ASDF generally doesn't reinvent version management, but wrap and re-use ruby-build, node-build etc.
It fails if your single project is a legacy monster needing four versions of node, two pythons and a handful of javas - but that's not a common use case.
More commonly you have multiple projects, each with a single version of node, python and java. For deployment you only need one of each - it's in development you need five of each when switching between projects.
robinhoodexe|1 year ago
[1] https://devenv.sh/
lexlash|1 year ago
Devenv seems nice (in fact it’s how I started down this path) but I haven’t found anything it does for me that I can’t get out of flakes - so far.
dave4420|1 year ago
- steep steep learning curve, so your team is split between those who can understand it and those who have to blindly follow checklists and ask for help when something breaks
- it doesn’t play well on macOS
karmakaze|1 year ago
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.
Historically I'd only cared about automating the spec of production environments. Why would I want/need this?
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?
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.
jdsalaro|1 year ago
always, golang is overly opinionated regarding where modules and binaries are stored. I don't like that and I've blown my local development environment into pieces because of that (looking at you GRPC, yikes)
But also, imagine that you, like me, need to test Python, Java+Kotlin+Gradle and NodeJS+Angular stuff. Do you really want to install _all that_ natively ? Just for a couple of merge reviews, and even if not, do you _really_ want to install all that natively ? The answer is always, IMHO, a resounding and clear no.
> 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?
For example, but also much worst, as mentioned in the OP it's to prevent the very real possibility of crippling your OS's language runtimes and also to stay productive.
lawik|1 year ago
It is quite helpful. Also incredibly practical when chevking whether Library X will work on an older version.
I do open source and consulting for clients. I deal with a lot of projects, my own and other's.
ufmace|1 year ago
pbowyer|1 year ago
jdsalaro|1 year ago
vorticalbox|1 year ago
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.
Been working like this for a couple of weeks now and it's pretty good.
If I end up breaking a box I can simply delete it and start over.
FireInsight|1 year ago
One project of mine, though, requires a shareable / pseudo-reproducible dev environment. Devbox didn't cut it, and mise especially couldn't have, since it requires some system deps. I went with a Nix Flake, which worked fine, but also started building a special distrobox image for the project, this time udimg Fedora as a base, as I perceived it as more stable. Using it too distrobox still had some issues, but I managed to make a shim/helper that runs `pnpm` from inside the container and that works pretty perfectly. Might be a bit worse on the performance side, though. We'll see.
jbverschoor|1 year ago
codethief|1 year ago
king_geedorah|1 year ago
bmitc|1 year ago
That's basically what asdf does, just automated.
eddyg|1 year ago
https://github.com/pyenv/pyenv
e12e|1 year ago
Generally asdf shines when you need more than one system installed - say a html or SQL language server that depends on node in addition to python for your main app.
fredrikaverpil|1 year ago
https://pkgx.sh
johnathon023|1 year ago
jdsalaro|1 year ago
> can activate project tooling upon cd’ing into a project folder
this probably can be replicated with zsh hooks: https://zsh.sourceforge.io/Doc/Release/Functions.html#Hook-F...
alanwreath|1 year ago
aooohan|1 year ago
https://github.com/version-fox/vfox
steph-123|1 year ago
See:https://x-cmd.com/pkg/
steph-123|1 year ago
doctorraags|1 year ago
That example in the article of managing multiple python 2.7 versions sounds like a horror story.
jdsalaro|1 year ago
> 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.
matsemann|1 year ago
.. 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.
pyinstallwoes|1 year ago
wudangmonk|1 year ago
jdsalaro|1 year ago
A couple of moons ago I used Poetry, but gave up on it because it was so heavy and unfortunately would bug out often.
tjoff|1 year ago
Nice in theory but not worth it.
cqqxo4zV46cp|1 year ago
seivan|1 year ago
Zizizizz|1 year ago
bandrami|1 year ago
neonsunset|1 year ago
elzbardico|1 year ago
victorbjorklund|1 year ago
lfmunoz4|1 year ago
lfmunoz4|1 year ago