[HN Gopher] Tools I love: mise(-en-place)
___________________________________________________________________
Tools I love: mise(-en-place)
Author : micvbang
Score : 130 points
Date : 2025-06-29 17:56 UTC (5 hours ago)
(HTM) web link (blog.vbang.dk)
(TXT) w3m dump (blog.vbang.dk)
| hacb wrote:
| So if I understand it correctly, it's a mix between GNU Make and
| `asdf`?
| micvbang wrote:
| Yep! And direnv on top of that :)
| pixelmonkey wrote:
| Author of mise has a page comparing it to asdf:
|
| https://mise.jdx.dev/dev-tools/comparison-to-asdf.html
| figmert wrote:
| On top of that, it also enabled environment management
| (replacing direnv). Env vars can also be retrieved from secret
| stores.
|
| It can also manage tools from various backends, e.g. go, aqua,
| cargo, npm, ubi and others
| vsviridov wrote:
| I wish they had some direct envrc support, so that legacy
| projects wouldn't have to be migrated to mise.toml
| kstrauser wrote:
| What does that "manage tools" bit get you? I started using
| mise as a replacement direnv a while ago and it's nice
| enough: cd into a directory and voila, the Python virtualenv
| is activated. I like that. But in what way could it manage,
| say, npm or cargo that would be useful?
|
| I feel like I'm missing something important here, as lots of
| people seem to adore mise, and I like it just fine for the
| limited use I put it to, but I haven't had that aha moment
| yet that makes it indispensable for me.
| maleldil wrote:
| You might need different versions of node, python, etc.,
| depending on the project. mise can manage those different
| versions for you, including installing and automatically
| enabling the correct version for each project.
| sureglymop wrote:
| Iirc it uses cargo directly as a mise backend. For example,
| instead of doing "cargo install ripgrep" you'd now install
| ripgrep through mise and could also have multiple versions
| of it.
|
| Maybe ripgrep is a bad example but imagine needing
| different versions of some dev tooling that can be
| installed with cargo install in different projects.
|
| Edit: thought you were asking about the npm and cargo
| backends specifically.
| linhns wrote:
| Somewhat, but it's easier to use than asdf
| foldr wrote:
| I use it just as a better asdf. I don't quite see the point of
| the rest of its functionality, but "asdf without needing to
| install plugins" is a compelling enough proposition for me.
| nchmy wrote:
| I'm in the same position at the moment, though I actually do
| see the point of the rest of the functionality. I just don't
| use it.
| vsviridov wrote:
| Recently completed a switch from asdf, and can confirm, this tool
| is great and it's now part of my base machine setup going
| forward.
| sausajez wrote:
| Hey, was reading your post and realised that your tag pages
| aren't working e.g. https://blog.vbang.dk/tag/mise/ Just in case
| you wanted to fix them
| micvbang wrote:
| Thanks a lot for telling me!
| hdjrudni wrote:
| Executables need to be more stable. I shouldn't have to manage
| versions this way at all. i.e., I should never need to downgrade
| a program. I think the Python 2 -> 3 fiasco broke everyone's
| brains.
| Etheryte wrote:
| Windows is the prime example of near infinite backwards
| compatibility. To an extent, less change and more backwards
| compatibility is good, but in my opinion, there definitely is
| such a thing as too much of it, too.
| __MatrixMan__ wrote:
| Wouldn't that be nice. Unfortunately people are naughty, so
| precisely pinned dependency versions are the next best thing.
| dayjah wrote:
| I have been using asdf for ~12 years, and made the switch to
| (what is now called) mise about ~4 years ago. This year I
| challenged myself to switch to nix. asdf and mise are essentially
| less virulent nix, after all. nix is a complete and utter phase
| shift for the better. However, the learning curve is steep due to
| atrocious documentation.
|
| If you're into these environment / tool managers I highly
| recommend giving nix a solid try for 4-6 months.
| stryan wrote:
| I'm lazy by nature so I don't like learning new tools if I don't
| have to. I've stuck with make, direnv, and my distros package
| manager instead of learning just or asdf so that I don't need to
| learn anything new. But mise hits that sweet spot of being a
| better direnv and a (mostly) better Make that it became worth the
| effort to try it out and I'm glad I did. It also helps that jdx
| (the author) really cares about the ergonomics of use and it
| shows; the documentation is up to date, the commands make sense,
| and every time I start to get annoyed some paper cut with it I
| discover there's already a fix for it (like `mise task run task-
| name` and `mise task-name` being equivalent commands so you don't
| have to type as much).
|
| If you try to stick to the classic POSIX tools since they're
| installed everywhere, I urge you to give mise a try anyway. It
| and fzf are the only programs I've found that are truly worth the
| extra effort it takes to install them, even if it is just
| grabbing a binary.
| elviejo wrote:
| I'll add the 'dtrx' (Do The Right Extraction) as one of those
| tools that are worth to learn compared to the more basic
| alternatives
| fmbb wrote:
| By "a better Make", do you mean Mise does phony target task-
| like recipes better?
|
| Or is it better than Make at actually making things, tracking
| file and recipe dependencies, detecting what needs to be
| rebuilt etc?
| jph wrote:
| mise is a great tool. One area where it doesn't work right out of
| the box is installing PostgreSQL via macOS brew, when I don't
| want to use Nix or Docker or Podman etc.
|
| Here's the solution I use; perhaps someone here has a better
| idea? brew install gcc readline zlib curl
| openssl@1.1 ossp-uuid icu4c pkg-config
| PKG_CONFIG_PATH="$(brew --prefix)/lib/pkgconfig:$(brew --prefix
| icu4c)/lib/pkgconfig" \ LDFLAGS="-L$(brew --prefix)/lib"
| \ CPPFLAGS="-I$(brew --prefix)/include" \ mise
| use postgres --verbose
| xyst wrote:
| This is what I have been doing to manage development
| environments:
|
| Workflows now revolve around nix.
|
| Setup a shell.nix that defines development environment (whether
| it's specific version of rust or python).
|
| Then `nix develop` will setup an isolated environment. Do some
| work on project. Then exit shell.
|
| No need to pollute machines environment with 100 versions of
| python/pip/uv.
|
| Add in `direnv` and it will automatically activate the nix shell
| upon `cd`. Plays well with gui editors too, assuming direnv
| plugin/tooling available.
| rkangel wrote:
| I do something very similar, although I'm still on nix-shell.
|
| It works really well.
| literalAardvark wrote:
| Almost as good as mise then, but using 2 tools, one of which no
| one likes to learn + insecure plugins
| victor_vhv wrote:
| We replaced _asdf_ in our dependency management for local
| development with _devbox_ (from _jetify_ ), it gave us the
| sweet spot between isolated shells (no _nix_ scripting) and
| easy configuration (dependencies go to devbox.json)
|
| With _asdf_ we ran into many troubles with broken
| dependencies due to wrongly installed system ( _brew_ ), etc.
| I fear with _miso_ we could end up in the same place.
|
| As a sidenote, I am starting to use _Taskfile_ to manage
| build scripts and such. Then I can easily reuse the scripts
| when I change the environment (i.e. use vendor containers in
| CI instead of _devbox_ ).
|
| I am trying to avoid mixing both concepts for better
| flexibility and less migration overhead.
| sergiotapia wrote:
| Interesting thank you for sharing. I've been using asdf for years
| now but I dislike the fact that you have to install plugins. I
| wish it just did stuff when I called commands.
|
| I'll try out Mise for Elixir, Erlang and NodeJS to see if it
| works like you describe.
| codethief wrote:
| > but I dislike the fact that you have to install plugins. I
| wish it just did stuff when I called commands.
|
| I used asdf for many years but this really annoyed me, too
| (along with a few other things). So I recently made the switch
| to mise and haven't looked back.
| mrbonner wrote:
| My actual usage is a mix-bag. For general tools and utilities, I
| often just use Nix and Home Manager. It is a pain for setting up
| but once you got it working, it's basically fire and forget.
| Whenever you need a new app, you just add that to the `home.nix`
| and call it a day.
|
| Now, for language development environment, I won't use Nix and
| just prefer to whatever that language popular choice. For
| instance, in Python I use uv. For Node I use npm (or yarn or bun
| or whatever in fashion now), Java has mice, Rust has rustup.
|
| It is not a one-size-fit-all solution but I am not sure if we can
| ever achieve that.
| hollerith wrote:
| >Rust has rustup.
|
| Do you mean cargo?
| tough wrote:
| Rustc is the compiler, rustup is the updater, cargo is the
| package manager.
| pdpi wrote:
| Cargo's the package manager and build tool, and doesn't
| really replace mise. Rustup, as the toolchain version
| manager, is the mise-equivalent for the Rust ecosystem.
| nylonstrung wrote:
| I'd argue nix is the closest to a one-size-fits-all solution if
| you're using stuff like uv2nix and npm equivalents
| mrbonner wrote:
| yes, but I now have to deal with all the oddities by
| combining them.
| sfn42 wrote:
| Java has mice? I thought java had maven and Gradle? Is mice a
| new thing?
| mrbonner wrote:
| My dang autocorrect, it is mise.
| rzzzt wrote:
| Java also has SDKMAN!, jabba and the "alternatives" mechanism
| in Linux distros:
|
| - https://sdkman.io/
|
| - https://github.com/shyiko/jabba
|
| - https://www.man7.org/linux/man-pages/man1/update-
| alternative...
| cheshire_cat wrote:
| Java is one of the few languages where I prefer the
| endemic/specialized version manager in the form of sdkman
| over mise. It has more Java versions available and also
| allows you to install a lot of the Java tooling like Gradle
| and Maven.
| nextos wrote:
| I love Nix flakes, but for some languages it is still very
| painful to use.
|
| For example, Julia has an unusual package management system and
| lots of packages still fail under flakes.
| hks0 wrote:
| I manage a monorepo at my workplace. Different devs with various
| levels of seniority are on/off boarded on the project, some on
| mac some on linux.
|
| At first I offered mise as the recommended tool, and after a
| while I declared it's the only supported way to build the project
| and boom! All support requests that used to end with "oooh my
| XYZ's version was not matching the project's requirement" are
| gone now.
|
| I like asdf but it has quirks. Mise has been a better companion
| for me past few years.
|
| I also hear people say "but my node/ruby/elixir/java/foo version
| manager will break. My team uses that tool in our other projects,
| etc, etc" then I only have to show them what an amazing drop-in
| replacement mise is and nothing breaks; there's no going back for
| them.
|
| I just hope muse stays mise, and doesn't become just[1] (whom I
| also install via mise)
|
| [1]: https://github.com/casey/just
| rsanheim wrote:
| Mise is fantastic. Switched from asdf awhile ago and have not
| looked back.
|
| I don't use the advanced task / env stuff, mostly just the tool
| management. Its been stable, fast, and gets out of the way.
| ukprogrammer wrote:
| can anyone comment on what their experience of using mise is vs.
| other tools a a la nix home-manager/flakes?
|
| I see this "one tool to rule them all" and instantly my senses go
| off that this is too good to be true to work in all the long-tail
| scenarios.
|
| There always seems to be some strange edge-cases with tools of
| this nature.
___________________________________________________________________
(page generated 2025-06-29 23:01 UTC)