11 ms·

Install Asdf: One Runtime Manager to Rule All Dev Environments

131 points by jdsalaro 2y ago

thedookmaster 2y ago
I've used asdf for years, but recently switched to https://github.com/jdx/mise 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. See: https://mise.jdx.dev/dev-tools/comparison-to-asdf.html https://mise.jdx.dev/dev-tools/comparison-to-asdf.html
- roylez 2y ago
  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.
  - seivan 2y ago
    [dead]
  - jdsalaro 2y ago
    I was only vaguely aware of rtx, but after discussing this post at length with people online they've made me aware of the rebranding and the general capabilities of mise. It sure is great, it is! However, like you, I tend to prefer minimalistic and predictable tools. That's why I decided to add the small comment in the discussion section of the post, to be fair but also kind of clear that bloating the runtime manager that was supposed to help manage the bloated runtimes and package managers isn't a great idea. Having said that, if the scope of mise stabilizes and it doesn't turn into a kitchen-sink kind of project, it sure seems sweet!
    - johnathon023 2y ago
      Mise’s #1 objective is to be a really great tool manager, just like ASDF, but way faster and smarter. However, it turns out that a tool that needs to be extremely CWD-aware also makes a great .env tool and task runner. I was also a little skeptical, but it’s actually super super useful. Especially because it’s easy to convince team members to install it for the tools, they get the rest for free with easy syntax.
      - jdxcode 2y ago
        You pretty much nailed it here. Env vars and tasks were kind of a happy accident—I implemented both inside of a day. (different days of course) Just because I realized I had all the building blocks to make them possible already, just needed to arrange them in a different way and they just appeared. In the future though I see tasks as being the headline for mise over tools. That's a ways out, certainly more than a year, but the thing about tasks is they don't suffer from the drawbacks that both PATH and shims have for putting your tools in the right place. In my personal use of mise I don't actually like using `mise activate` whatsoever. The problem is just that I can't yet do everything with tasks easily enough. Tasks need to get to a point where they're so easy you won't want to bother with having tools in your shell. Though who knows. I may be off my rocker on that one. I certainly get things wrong as much, if not more, than I get them right.
    - jdxcode 2y ago
      Mise does a lot of things and I don't buy into the unix philosophy so you may not like it (which is totally fine btw, my goal is not at all for everyone to love it). That said, I think if you thought about _why_ you like minimalistic and predictable tools you may find that mise solves the underlying reasons for that. My whole thing is about augmenting your environment and not replacing it. This is generally where I contrast mise with tools like nix and docker but I thought it was worth calling out. I think people like mise because they can use it for just setting some env vars, installing a few npm packages globally, having an easy way to synchronize tool versions between local dev and CI/CD. You can use it for any one of those things and it slots right in wherever you are—whether that's inside VSCode, ssh'ed into a remote machine, in a github action, or inside a docker container in a k8s fleet. Yeah mise is capable of a lot of different things, but the important thing is that it doesn't force you to change anything _else_ about your setup.
- quickslowdown 2y ago
  I recently started using https://github.com/prefix-dev/pixi 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.
  - jdsalaro 2y ago
    > I recently started using https://github.com/prefix-dev/pixi https://github.com/prefix-dev/pixi for Python projects Why is it based on the Conda ecosystem? Do you happen to know? I assume it's for portability, but that sounds heavy.
    - abkfenris 2y ago
      For as much improvement as there has been with what can be distributed via PyPI, there are still some domains that have gnarlier dependencies than wheels happily handle alone, and you either need to reach for the system package manager (and loose the ability to really control the dependency environment from that mismatch), or take advantage of the Conda ecosystem. My org does a lot of work combining machine learning with oceanographic and climate modeling, which are both domains that have deep dependency chains that don't always mesh well, especially as our researchers mix in R and other languages as the same time, and the Conda ecosystem helps us a ton with that, but there are issues that `conda` and `mamba` don't help us out with. Pixi takes a swing at some of what the Conda ecosystem hasn't been great at (at least without a lot of manual custom ceremony) that Cargo, Poetry, Pipenv, PDM, and other dependency and workflow management tools have demonstrated can be done such as lock files, cross platform dependency management, task running, and defining multiple related environments. What's really cool when you have a mix of projects, Pixi can work almost entirely PyPI native out of a `pyproject.toml`, other than installing Python from Conda-Forge, so you can mix and match environments but stay with the same tool. https://prefix.dev/blog/using_python_projects_with_pixi https://prefix.dev/blog/using_python_projects_with_pixi docs: https://pixi.sh/latest/advanced/pyproject_toml/ https://pixi.sh/latest/advanced/pyproject_toml/
  - bmitc 2y ago
    Why this over Poetry? asdf handles tools, not really packages. So asdf would install Python and not Python packages.
- cholindo 2y ago
  +1
- oakesm9 2y ago
  I did the same. mise is brilliant! For reference it was previously called rtx The main differences are better UX with simpler commands and it not using shims, which means much better performance
  - chem83 2y ago
    mise borrows the plugins from asdf, which also makes it non-cross platform. Interesting discussion on this topic on their GitHub: https://github.com/jdx/mise/discussions/66 https://github.com/jdx/mise/discussions/66 Solutions considered include adopting the vfox plugin system or transpiling all asdf plugins to ShellJs. Now I know that vfox exists.
    - jdxcode 2y ago
      I made some progress on windows last week! I'm working on making it so vfox plugins can be used as the "default" backend instead of asdf which will be a prerequisite for windows support. Step 1 is being able to run vfox plugins inside of rust which I got pretty far on: https://github.com/jdx/vfox.rs https://github.com/jdx/vfox.rs It'll be a long road ahead and I could certainly use some help if anyone out there is interested in moving it forward. That said, vfox is a really great project and they are targeting windows specifically. Windows will probably always be second in the mise ecosystem (because I don't use it) but my hope is I can get at least a baseline of support which would help teams that have occasional windows contributors.
      - chem83 2y ago
        Amazing! Great to hear you're thinking about / working on this.
- abrookewood 2y ago
  Ah - was just about to come and post exactly the same thing. Mise is fantastic, supports everything ASDF does and is faster.
- jauntywundrkind 2y ago
  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.
  - bin_bash 2y ago
    you can use shims with mise
    - shepherdjerred 2y ago
      +1 I switched from asdf to mise and everything works fine _if_ you setup shims.
    - e12e 2y ago
      Thank you for pointing that out - that means I can actually use mise (probably). https://mise.jdx.dev/dev-tools/shims.html https://mise.jdx.dev/dev-tools/shims.html
- hk1337 2y ago
  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”.
  - mynameisvlad 2y ago
    I mean you can apply this argument to just about anything, it isn’t really unique to “this industry” or computing in general. People will generally change taste and likes/dislikes every few years.
  - dorian-graph 2y ago
    > Just as one starts getting popular ... asdf hasn't just started getting popular. It's been popular for a long time already. IIRC I started using it ~8 years ago (~2016). asdf has been around since 2014. I believe Mise (rtx) has been around for a couple of years already too.
    - hk1337 2y ago
      Fair. Honestly, I hadn't heard of it until about a year ago, up until then I was using pyenv and rbenv independently.
      - Mo3 2y ago
        Same here. Never heard of it until a few months ago when I got back into Ruby on Rails after 12 years. Also, contrary to the other comments in this chain I don't find it particularly slow..
  - sgarland 2y ago
    The main issue most people have with asdf is that it’s annoyingly slow. Not unusably so, but just enough that it’s irritating. I identified [0] the source for much of it (sub-shells and pipes) and began a PR [1], but became bogged down with BATS testing, and then found mise / rtx, so kind of lost interest. Sorry. You can always implement these if you’d like. [0]: https://github.com/asdf-vm/asdf/issues/290#issuecomment-1383056355 https://github.com/asdf-vm/asdf/issues/290#issuecomment-1383... [1]: https://github.com/asdf-vm/asdf/pull/1441 https://github.com/asdf-vm/asdf/pull/1441
fredrikaverpil 2y ago
I’m liking pkgx over asdf as it can activate project tooling upon cd’ing into a project folder. https://pkgx.sh https://pkgx.sh
- jdsalaro 2y ago
  it certainly looks interesting! I'm still not sure if "It’s npx for everything else" is good marketing :P > 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-Functions https://zsh.sourceforge.io/Doc/Release/Functions.html#Hook-F...
- johnathon023 2y ago
  Mise gives you basically the same capabilities but is scoped a bit better, I’d check it out.
  - drewbitt 2y ago
    Is it? On top of an asdf and direnv replacement, mise is also a task runner, an environment variable manager, has experimental backends for npm/rust/go/python etc to take over their global package installs, replaces core asdf plugins with rewrites they have to maintain, and more. If anything it actually fails to scope itself (Note: I like the tool)
- alanwreath 2y ago
  wait wuuut? I don't get it, I do this with asdf using the `.tool-versions` file. What's the difference/improvement?
matsemann 2y ago
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.
- seivan 2y ago
  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.
  - jdsalaro 2y ago
    this makes me itchy, pulling the whole internet without looking into your development machine sounds like a very bad idea. It's the equivalent of an IDE's "do you trust this project" but on steroids.
    - seivan 2y ago
      [dead]
  - elbear 2y ago
    Nix with direnv does that, but without Docker.
- cqqxo4zV46cp 2y ago
  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.
- 2y ago
noobermin 2y ago
Wait, not only is it called asdf leading to confusion, it literally is also a package manager of sorts just like the original asdf??? 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?
- phinnaeus 2y ago
  What's the "original asdf?"
  - ReleaseCandidat 2y ago
    https://asdf.common-lisp.dev/ https://asdf.common-lisp.dev/
  - guenthert 2y ago
    https://en.wikipedia.org/wiki/Another_System_Definition_Facility https://en.wikipedia.org/wiki/Another_System_Definition_Faci... (it's bit like Python stealing the name of a CL compiler ...)
    - bmitc 2y ago
      asdf is not Python specific.
      - Y_Y 2y ago
        Correct, asdf will work with other Common Lisp compilers.
        bmitc 2y ago
        :|
- 000ooo000 2y ago
  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.
doctorraags 2y ago
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.
- jdsalaro 2y ago
  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.
  - iforgotmysocks 2y ago
    > brew's Python installation on MacOS as are Debian's and Ubuntu's are _extremely_ brittle 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).
  - brabel 2y ago
    You shouldn't need asdf to work with JVM stuff. I would suggest learning how to use SDKMAN: https://sdkman.io/ https://sdkman.io/ 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> That's all. 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 If you need to do anything else, you should complain to the project authors as this is really all you should need!
steph-123 2y ago
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 See:https://x-cmd.com/pkg/ https://x-cmd.com/pkg/
- steph-123 2y ago
  it portability
pbowyer 2y ago
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.
- jdsalaro 2y ago
  there's something I don't get, why do you have globally installed tools that asdf can manage at the same time that you have asdf installed?
  - pbowyer 2y ago
    So that in any directory you can type `<command name>`? asdf Node installs aren't like Python virtual environments; they're centrally installed and one Node version (and its packages) is shared across all diretories that want it + global tools.
    - jdsalaro 2y ago
      > So that in any directory you can type `<command name>`? Any tool installed via asdf is available on any directory as long as you are accessing that directory via a shell spawned with a .profilerc or similar which contains your asdf configuration. > asdf Node installs aren't like Python virtual environments Correct, neither should they be. > they're centrally installed and one Node version (and its packages) is shared across all diretories sure, they are, and that's by design. You're conflating a runtime manager with a package manager. Venvs are _not_ runtime manager, the moment you need another Python version you're done for. asdf.vm is _not_ a package manager, the moment you want package isolation while working on an asdf install is the moment you install yourself pipenv, poetry, pdm or use python venvs for that. > that want it + global tools. which is achieved as I've shown below. Still, there was no reason in your usecase to modify or play with globally installed tools besides asdf, through which you can then define global runtime versions and those global versions will hold your global tools, usable wherever.
robinhoodexe 2y ago
Sounds like nix using devenv[1] also would solve this problem. [1] https://devenv.sh/ https://devenv.sh/
- lexlash 2y ago
  Having tried asdf - among other tools - for awhile, dropping it for nix+flakes+direnv was great. 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.
  - robinhoodexe 2y ago
    I'm considering doing a pilot (~5 devs out of 120) with using nix to manage dependencies and build containers at $DAYJOB, and here I think devenv is nice as a "one package" plus an active community for support.
    - lexlash 2y ago
      95% of the difficulty I have at $DAYJOB is nix installation and dealing with enterprise certificate/auth crud…sadly devenv doesn’t help much there. Our pilot is quite a bit larger. Sticking to plainer flakes has made it easier for folks to self-service for now but we do intend to re-evaluate devenv. Same username on twitter if you’re interested in chatting.
- dave4420 2y ago
  Yeah… but then you get nix’s problems. - 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
  - mg74 2y ago
    How doesnt it play well one MacOS? I've been using Nix Home Manager + Nix Darwin as my package manager, and Direnv + Nix Shell for developer environments; and havent had any problems (yet). Is there something I should be aware of? Agree about the learning curve; but I am going to experience onboarding my coworkers onto using Nix only for developer environments over the next months; I feel the curve is not quite that steep for that limited use case.
jbverschoor 2y ago
I created https://github.com/jrz/container-shell https://github.com/jrz/container-shell to add a layer of security / isolation in addition to tools like asdf.
- codethief 2y ago
  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.
  - jbverschoor 2y ago
    If the dotfiles are in the project dir, they'll be exposed of course. If not, perhaps a bind mount from ~/.config would work, but it could also unintentionally expose files on the host. It is possible to bind-mount individual files, so perhaps having a list of exposed config files / mappings could work. The problem with this is that docker doesn't like it when not all mounts are found, so within a team it requires something more sophisticated.
king_geedorah 2y ago
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?
- eddyg 2y ago
  If you have a requirement for multiple, specific Python versions, why not just use pyenv? https://github.com/pyenv/pyenv https://github.com/pyenv/pyenv
  - king_geedorah 2y ago
    That's not an unreasonable question. I don't really have a good answer to it outside of I found building and installing the couple that I needed myself to be fine and don't mind invoking as `python3.11` or what have you, since it's only different when I'm initialising my venvs.
- bmitc 2y ago
  > 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. That's basically what asdf does, just automated.
  - king_geedorah 2y ago
    Does asdf automatically pull in its own copies of libraries for relevant functionality? For example I needed headers for readline in order to get that going on my compiled interpreters. If it avoids that then that could be a reason to use one over the other at least on new systems. Edit: Decided to peruse the code for the python asdf plugin myself and it seems to just use pyenv under the hood anyway, so I guess it's not really a question of what asdf does anyway.
lexlash 2y ago
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.)
- iainmerrick 2y ago
  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.
  - brabel 2y ago
    Every language has a tool like NPM (actually, nvm in the context of this discussion) these days. The problems tools like Nix solves (and arguably, Asdf) is that instead of learning each language's tools you only need to learn one tool that manages multiple languages and system dependencies.
- e12e 2y ago
  > 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.
karmakaze 2y ago
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.
- jdsalaro 2y ago
  > Why would I want/need this? 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.
  - brabel 2y ago
    IMHO the solution for the problem of devs in the same company having different environments is not Adsf and its competitors like Mise, but things like Nix/Guix and Docker. At work, because everyone uses Mac, we ended up using Kandji to achieve the same thing: everyone has the same tools and environments, but that is only if you already have to use that due to security audits and stuff like that. If I had a small company myself I would probably setup everything with Guix as I really like the way it works, more than Nix (though only because I prefer Lisp config files and because Guix doesn't suffer from any polemics like the flake soap opera).
elzbardico 2y ago
At some time I just decided that having different users is the best runtime manager of all.
neonsunset 2y ago
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.
Zizizizz 2y ago
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.
vorticalbox 2y ago
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.
- FireInsight 2y ago
  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.
victorbjorklund 2y ago
Does people use asdf in prod? Or just on dev machines?
- lfmunoz4 2y ago
  wondering the same thing and is why I use Nix right now. I.e, works in prod / dev
bandrami 2y ago
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)
aooohan 2y ago
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. https://github.com/version-fox/vfox https://github.com/version-fox/vfox
lfmunoz4 2y ago
what are the benefits of this verses using Nix?

131 points by jdsalaro 2y ago

I've used asdf for years, but recently switched to https://github.com/jdx/mise 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. See: https://mise.jdx.dev/dev-tools/comparison-to-asdf.html https://mise.jdx.dev/dev-tools/comparison-to-asdf.html

roylez 2y ago
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.
- seivan 2y ago
  [dead]
- jdsalaro 2y ago
  I was only vaguely aware of rtx, but after discussing this post at length with people online they've made me aware of the rebranding and the general capabilities of mise. It sure is great, it is! However, like you, I tend to prefer minimalistic and predictable tools. That's why I decided to add the small comment in the discussion section of the post, to be fair but also kind of clear that bloating the runtime manager that was supposed to help manage the bloated runtimes and package managers isn't a great idea. Having said that, if the scope of mise stabilizes and it doesn't turn into a kitchen-sink kind of project, it sure seems sweet!
  - johnathon023 2y ago
    Mise’s #1 objective is to be a really great tool manager, just like ASDF, but way faster and smarter. However, it turns out that a tool that needs to be extremely CWD-aware also makes a great .env tool and task runner. I was also a little skeptical, but it’s actually super super useful. Especially because it’s easy to convince team members to install it for the tools, they get the rest for free with easy syntax.
    - jdxcode 2y ago
      You pretty much nailed it here. Env vars and tasks were kind of a happy accident—I implemented both inside of a day. (different days of course) Just because I realized I had all the building blocks to make them possible already, just needed to arrange them in a different way and they just appeared. In the future though I see tasks as being the headline for mise over tools. That's a ways out, certainly more than a year, but the thing about tasks is they don't suffer from the drawbacks that both PATH and shims have for putting your tools in the right place. In my personal use of mise I don't actually like using `mise activate` whatsoever. The problem is just that I can't yet do everything with tasks easily enough. Tasks need to get to a point where they're so easy you won't want to bother with having tools in your shell. Though who knows. I may be off my rocker on that one. I certainly get things wrong as much, if not more, than I get them right.
  - jdxcode 2y ago
    Mise does a lot of things and I don't buy into the unix philosophy so you may not like it (which is totally fine btw, my goal is not at all for everyone to love it). That said, I think if you thought about _why_ you like minimalistic and predictable tools you may find that mise solves the underlying reasons for that. My whole thing is about augmenting your environment and not replacing it. This is generally where I contrast mise with tools like nix and docker but I thought it was worth calling out. I think people like mise because they can use it for just setting some env vars, installing a few npm packages globally, having an easy way to synchronize tool versions between local dev and CI/CD. You can use it for any one of those things and it slots right in wherever you are—whether that's inside VSCode, ssh'ed into a remote machine, in a github action, or inside a docker container in a k8s fleet. Yeah mise is capable of a lot of different things, but the important thing is that it doesn't force you to change anything _else_ about your setup.
quickslowdown 2y ago
I recently started using https://github.com/prefix-dev/pixi 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.
- jdsalaro 2y ago
  > I recently started using https://github.com/prefix-dev/pixi https://github.com/prefix-dev/pixi for Python projects Why is it based on the Conda ecosystem? Do you happen to know? I assume it's for portability, but that sounds heavy.
  - abkfenris 2y ago
    For as much improvement as there has been with what can be distributed via PyPI, there are still some domains that have gnarlier dependencies than wheels happily handle alone, and you either need to reach for the system package manager (and loose the ability to really control the dependency environment from that mismatch), or take advantage of the Conda ecosystem. My org does a lot of work combining machine learning with oceanographic and climate modeling, which are both domains that have deep dependency chains that don't always mesh well, especially as our researchers mix in R and other languages as the same time, and the Conda ecosystem helps us a ton with that, but there are issues that `conda` and `mamba` don't help us out with. Pixi takes a swing at some of what the Conda ecosystem hasn't been great at (at least without a lot of manual custom ceremony) that Cargo, Poetry, Pipenv, PDM, and other dependency and workflow management tools have demonstrated can be done such as lock files, cross platform dependency management, task running, and defining multiple related environments. What's really cool when you have a mix of projects, Pixi can work almost entirely PyPI native out of a `pyproject.toml`, other than installing Python from Conda-Forge, so you can mix and match environments but stay with the same tool. https://prefix.dev/blog/using_python_projects_with_pixi https://prefix.dev/blog/using_python_projects_with_pixi docs: https://pixi.sh/latest/advanced/pyproject_toml/ https://pixi.sh/latest/advanced/pyproject_toml/
- bmitc 2y ago
  Why this over Poetry? asdf handles tools, not really packages. So asdf would install Python and not Python packages.
cholindo 2y ago
+1
oakesm9 2y ago
I did the same. mise is brilliant! For reference it was previously called rtx The main differences are better UX with simpler commands and it not using shims, which means much better performance
- chem83 2y ago
  mise borrows the plugins from asdf, which also makes it non-cross platform. Interesting discussion on this topic on their GitHub: https://github.com/jdx/mise/discussions/66 https://github.com/jdx/mise/discussions/66 Solutions considered include adopting the vfox plugin system or transpiling all asdf plugins to ShellJs. Now I know that vfox exists.
  - jdxcode 2y ago
    I made some progress on windows last week! I'm working on making it so vfox plugins can be used as the "default" backend instead of asdf which will be a prerequisite for windows support. Step 1 is being able to run vfox plugins inside of rust which I got pretty far on: https://github.com/jdx/vfox.rs https://github.com/jdx/vfox.rs It'll be a long road ahead and I could certainly use some help if anyone out there is interested in moving it forward. That said, vfox is a really great project and they are targeting windows specifically. Windows will probably always be second in the mise ecosystem (because I don't use it) but my hope is I can get at least a baseline of support which would help teams that have occasional windows contributors.
    - chem83 2y ago
      Amazing! Great to hear you're thinking about / working on this.
abrookewood 2y ago
Ah - was just about to come and post exactly the same thing. Mise is fantastic, supports everything ASDF does and is faster.
jauntywundrkind 2y ago
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.
- bin_bash 2y ago
  you can use shims with mise
  - shepherdjerred 2y ago
    +1 I switched from asdf to mise and everything works fine _if_ you setup shims.
  - e12e 2y ago
    Thank you for pointing that out - that means I can actually use mise (probably). https://mise.jdx.dev/dev-tools/shims.html https://mise.jdx.dev/dev-tools/shims.html
hk1337 2y ago
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”.
- mynameisvlad 2y ago
  I mean you can apply this argument to just about anything, it isn’t really unique to “this industry” or computing in general. People will generally change taste and likes/dislikes every few years.
- dorian-graph 2y ago
  > Just as one starts getting popular ... asdf hasn't just started getting popular. It's been popular for a long time already. IIRC I started using it ~8 years ago (~2016). asdf has been around since 2014. I believe Mise (rtx) has been around for a couple of years already too.
  - hk1337 2y ago
    Fair. Honestly, I hadn't heard of it until about a year ago, up until then I was using pyenv and rbenv independently.
    - Mo3 2y ago
      Same here. Never heard of it until a few months ago when I got back into Ruby on Rails after 12 years. Also, contrary to the other comments in this chain I don't find it particularly slow..
- sgarland 2y ago
  The main issue most people have with asdf is that it’s annoyingly slow. Not unusably so, but just enough that it’s irritating. I identified [0] the source for much of it (sub-shells and pipes) and began a PR [1], but became bogged down with BATS testing, and then found mise / rtx, so kind of lost interest. Sorry. You can always implement these if you’d like. [0]: https://github.com/asdf-vm/asdf/issues/290#issuecomment-1383056355 https://github.com/asdf-vm/asdf/issues/290#issuecomment-1383... [1]: https://github.com/asdf-vm/asdf/pull/1441 https://github.com/asdf-vm/asdf/pull/1441

fredrikaverpil 2y ago

I’m liking pkgx over asdf as it can activate project tooling upon cd’ing into a project folder. https://pkgx.sh https://pkgx.sh

jdsalaro 2y ago
it certainly looks interesting! I'm still not sure if "It’s npx for everything else" is good marketing :P > 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-Functions https://zsh.sourceforge.io/Doc/Release/Functions.html#Hook-F...
johnathon023 2y ago
Mise gives you basically the same capabilities but is scoped a bit better, I’d check it out.
- drewbitt 2y ago
  Is it? On top of an asdf and direnv replacement, mise is also a task runner, an environment variable manager, has experimental backends for npm/rust/go/python etc to take over their global package installs, replaces core asdf plugins with rewrites they have to maintain, and more. If anything it actually fails to scope itself (Note: I like the tool)
alanwreath 2y ago
wait wuuut? I don't get it, I do this with asdf using the `.tool-versions` file. What's the difference/improvement?

matsemann 2y ago

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.

seivan 2y ago
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.
- jdsalaro 2y ago
  this makes me itchy, pulling the whole internet without looking into your development machine sounds like a very bad idea. It's the equivalent of an IDE's "do you trust this project" but on steroids.
  - seivan 2y ago
    [dead]
- elbear 2y ago
  Nix with direnv does that, but without Docker.
cqqxo4zV46cp 2y ago
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.
2y ago

noobermin 2y ago

Wait, not only is it called asdf leading to confusion, it literally is also a package manager of sorts just like the original asdf??? 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?

phinnaeus 2y ago
What's the "original asdf?"
- ReleaseCandidat 2y ago
  https://asdf.common-lisp.dev/ https://asdf.common-lisp.dev/
- guenthert 2y ago
  https://en.wikipedia.org/wiki/Another_System_Definition_Facility https://en.wikipedia.org/wiki/Another_System_Definition_Faci... (it's bit like Python stealing the name of a CL compiler ...)
  - bmitc 2y ago
    asdf is not Python specific.
    - Y_Y 2y ago
      Correct, asdf will work with other Common Lisp compilers.
      - bmitc 2y ago
        :|
000ooo000 2y ago
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.

doctorraags 2y ago

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.

jdsalaro 2y ago
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.
- iforgotmysocks 2y ago
  > brew's Python installation on MacOS as are Debian's and Ubuntu's are _extremely_ brittle 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).
- brabel 2y ago
  You shouldn't need asdf to work with JVM stuff. I would suggest learning how to use SDKMAN: https://sdkman.io/ https://sdkman.io/ 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> That's all. 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 If you need to do anything else, you should complain to the project authors as this is really all you should need!

steph-123 2y ago

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 See:https://x-cmd.com/pkg/ https://x-cmd.com/pkg/

steph-123 2y ago
it portability

pbowyer 2y ago

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.

jdsalaro 2y ago
there's something I don't get, why do you have globally installed tools that asdf can manage at the same time that you have asdf installed?
- pbowyer 2y ago
  So that in any directory you can type `<command name>`? asdf Node installs aren't like Python virtual environments; they're centrally installed and one Node version (and its packages) is shared across all diretories that want it + global tools.
  - jdsalaro 2y ago
    > So that in any directory you can type `<command name>`? Any tool installed via asdf is available on any directory as long as you are accessing that directory via a shell spawned with a .profilerc or similar which contains your asdf configuration. > asdf Node installs aren't like Python virtual environments Correct, neither should they be. > they're centrally installed and one Node version (and its packages) is shared across all diretories sure, they are, and that's by design. You're conflating a runtime manager with a package manager. Venvs are _not_ runtime manager, the moment you need another Python version you're done for. asdf.vm is _not_ a package manager, the moment you want package isolation while working on an asdf install is the moment you install yourself pipenv, poetry, pdm or use python venvs for that. > that want it + global tools. which is achieved as I've shown below. Still, there was no reason in your usecase to modify or play with globally installed tools besides asdf, through which you can then define global runtime versions and those global versions will hold your global tools, usable wherever.

robinhoodexe 2y ago

Sounds like nix using devenv[1] also would solve this problem. [1] https://devenv.sh/ https://devenv.sh/

lexlash 2y ago
Having tried asdf - among other tools - for awhile, dropping it for nix+flakes+direnv was great. 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.
- robinhoodexe 2y ago
  I'm considering doing a pilot (~5 devs out of 120) with using nix to manage dependencies and build containers at $DAYJOB, and here I think devenv is nice as a "one package" plus an active community for support.
  - lexlash 2y ago
    95% of the difficulty I have at $DAYJOB is nix installation and dealing with enterprise certificate/auth crud…sadly devenv doesn’t help much there. Our pilot is quite a bit larger. Sticking to plainer flakes has made it easier for folks to self-service for now but we do intend to re-evaluate devenv. Same username on twitter if you’re interested in chatting.
dave4420 2y ago
Yeah… but then you get nix’s problems. - 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
- mg74 2y ago
  How doesnt it play well one MacOS? I've been using Nix Home Manager + Nix Darwin as my package manager, and Direnv + Nix Shell for developer environments; and havent had any problems (yet). Is there something I should be aware of? Agree about the learning curve; but I am going to experience onboarding my coworkers onto using Nix only for developer environments over the next months; I feel the curve is not quite that steep for that limited use case.

jbverschoor 2y ago

I created https://github.com/jrz/container-shell https://github.com/jrz/container-shell to add a layer of security / isolation in addition to tools like asdf.

codethief 2y ago
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.
- jbverschoor 2y ago
  If the dotfiles are in the project dir, they'll be exposed of course. If not, perhaps a bind mount from ~/.config would work, but it could also unintentionally expose files on the host. It is possible to bind-mount individual files, so perhaps having a list of exposed config files / mappings could work. The problem with this is that docker doesn't like it when not all mounts are found, so within a team it requires something more sophisticated.

king_geedorah 2y ago

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?

eddyg 2y ago
If you have a requirement for multiple, specific Python versions, why not just use pyenv? https://github.com/pyenv/pyenv https://github.com/pyenv/pyenv
- king_geedorah 2y ago
  That's not an unreasonable question. I don't really have a good answer to it outside of I found building and installing the couple that I needed myself to be fine and don't mind invoking as `python3.11` or what have you, since it's only different when I'm initialising my venvs.
bmitc 2y ago
> 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. That's basically what asdf does, just automated.
- king_geedorah 2y ago
  Does asdf automatically pull in its own copies of libraries for relevant functionality? For example I needed headers for readline in order to get that going on my compiled interpreters. If it avoids that then that could be a reason to use one over the other at least on new systems. Edit: Decided to peruse the code for the python asdf plugin myself and it seems to just use pyenv under the hood anyway, so I guess it's not really a question of what asdf does anyway.

lexlash 2y ago

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.)

iainmerrick 2y ago
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.
- brabel 2y ago
  Every language has a tool like NPM (actually, nvm in the context of this discussion) these days. The problems tools like Nix solves (and arguably, Asdf) is that instead of learning each language's tools you only need to learn one tool that manages multiple languages and system dependencies.
e12e 2y ago
> 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.

karmakaze 2y ago

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.

jdsalaro 2y ago
> Why would I want/need this? 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.
- brabel 2y ago
  IMHO the solution for the problem of devs in the same company having different environments is not Adsf and its competitors like Mise, but things like Nix/Guix and Docker. At work, because everyone uses Mac, we ended up using Kandji to achieve the same thing: everyone has the same tools and environments, but that is only if you already have to use that due to security audits and stuff like that. If I had a small company myself I would probably setup everything with Guix as I really like the way it works, more than Nix (though only because I prefer Lisp config files and because Guix doesn't suffer from any polemics like the flake soap opera).

elzbardico 2y ago

At some time I just decided that having different users is the best runtime manager of all.

neonsunset 2y ago

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.

Zizizizz 2y ago

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.

vorticalbox 2y ago

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.

FireInsight 2y ago
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.

victorbjorklund 2y ago

Does people use asdf in prod? Or just on dev machines?

lfmunoz4 2y ago
wondering the same thing and is why I use Nix right now. I.e, works in prod / dev

bandrami 2y ago

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)

aooohan 2y ago

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. https://github.com/version-fox/vfox https://github.com/version-fox/vfox

lfmunoz4 2y ago

what are the benefits of this verses using Nix?