5 ms·

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 som

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

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

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