Many OS's have their own (sometimes multiple) container technologies, but the ecosystem and zeitgeist revolves around OCI Linux containers.

So it's more cultural than technical. I believe you can run OCI Windows containers on Windows with no VM, although I haven't tried this myself.

"Don't retract bookmark sub-menus after drag and drop" - The 17 year old issue (2008) was locked for comments recently, so I don't have any other way to celebrate. I've been subscribed to this issue for over half of my life. I can't say I really care about it anymore, but it feels momentous enough to warrant sharing.

I was the original poster and was just about to post the same thing!

We really need to celebrate and bring out the Champagne :-)

I've been using `git summary` from tj/git-extras for a while. It seems to do a similar job.

The two most popular zsh plugins are total clones of this at 31k and 20k gh stars respectively. Not an award but certainly an indication of its success.

Having used zsh with those plugins for a while and not having used fish personally, I'll nominate them for "most desirable plugins to copy for your own shell to make it more user-friendly".

> that uses a tool that is not yet in mise registry

Yes, you can directly get tools from npm/pypi/cargo/github-releases/asdf-plugins/vfox-plugins without anyone touching the mise registry. The registry is just a convenient index of short names e.g. "fzf@0.56.3" maps to ubi:junegunn/fzf@0.56.3 which will download the appropriate arch binary from the v0.56.3 junegunn/fzf GitHub release.

> if I want to provide a python runtime that is compiled slightly differently

The default uses precompiled binaries, but with one setting it can use python-build/pyenv under the hood, then all the pyenv env vars can be used to configure the build process.

I feel like nix has been thoroughly discussed in this post already, so you're not the only guy.

> You don't need to mess around with shell hacks

Shell integration is optional, you can use `mise en` just like `nix-shell` or `nix develop`. You could also just invoke commands/scripts through mise tasks or mise exec.

> based on a string in one of several dozen dotfiles

The "Idiomatic" files like .nvmrc, .python-version, etc are supported but most people just use a mise.toml, which (a bit like flake files) contains all the config for the environment.

> but when tools are published through NPM or RubyGems or Crates or just on github that you have to run `go install` to get, then it's a bit of faff

And this is what mise excels at: `mise use npm:cowsay` or `mise use ubi:junegunn/fzf`

I think Nix/Guix are great, but also terrible. For me today, it's not worth the pain.

`mise use uv`, there, I fixed it for you.

Mise actually has a great integration with uv, like auto venv activation.

I think uv has auto venv activation and workspaces and stuff, now that uv is the official successor of Rye?

It does but you need to run commands through uv to use it, I assume this means if you run bare python commands in the task runner or whatever mise will use the venv.

All the features are opt-in. I started using mise because I wanted something like asdf only without the bad UX, and mise can use asdf plugins.

For env vars, you don't need to load them into your shell if you don't want to. When you run a task, mise will make sure the env vars in your config are set, so thats not something you need to worry about.

I still use shell scripts like you describe, mise just supercharges them a bit. When I need to make sure my teammates have the tools in that script (like jq) installed, mise just ensure they are installed before running the command, as long as you declare them in your tools list.

If your setup works for you thats great.

I've been using asdf for years. So far it works great but sometimes the shims breaks which kinda annoys me.

Was it worth the switch?

Definitely, the CLI is more intuitive, and using paths instead of shims makes it faster and more reliable.

I'm using it to unify my teams toolchain without resorting to nix or running everything in docker.

I still use docker to run services and I still like the idea of nix, but the DX of mise is too good. Tasks are really nice too, all my repo scripts now have completions.

Did you try https://devenv.sh/? It uses Nix under the hood but with an improved DX experience. I haven't used it myself personally since I find Nix good enough but I am curious if you would still choose mise over devenv.

We are starting to adopt devenv in our team. Overall it's really good--we have control over our toolchain, environment, and the processes that we start. There are some lingering papercuts though, like they haven't yet released a version where they allow specifying the Go toolchain version, and they seem to periodically re-download the Nix package archive. But I think they are improving fairly quickly.

Ultimately, we might still end up moving to straight Nix flakes, just not sure yet.

> they haven't yet released a version where they allow specifying the Go toolchain version

Devenv's maintainers are friendly and responsive when it comes to contributions from downstream, and like 90% of the devenv repo is plain ol' Nix code written in idioms that are common in the community.

I mention it because my team has hit some papercuts as well, but I've been really happy with how easy it's proven to address them. :)

I agree, the fix is in the main branch, they just haven't released it yet. It's just that the existing released versions just don't allow customizing the Go version because of some hardcoded assumptions in the Nix code. So I'll wait for the released version. I did say these are papercuts, not showstoppers ;-)

I'd be interested in anybody who has tried https://devenv.sh/ and https://www.jetify.com/devbox and chosen one over the other. Tried devbox which has been good, but not devenv.

Thanks that is useful

I briefly tried devenv and I find it much easier to use than raw nix, but I also had issues with my nix install on macos (using both the official and the DS installer). It worked well on my linux machine.

Today though mise has so many other great features, I would still choose it over devenv or devbox.

I've used Devbox for two years for my projects and any work I've done for my clients.

I'm curious what some of the mise features are you like.

I like Devbox and I'm familiar with its features so I'll just mention the extras the mise has.

The ubi backend means I can use nearly any binary published on GitHub without needing to worry about a flake or nixpkgs. Just get the binary directly from the author. Same for many of the other backends https://mise.jdx.dev/dev-tools/backends/.

Tasks are very powerful, they can use dependencies, flags, args, completions, and watches. Also can be defined either as strings in the config or point to shell scripts or even python/node/whatever scripts.

The shebang trick is very fun for writing portable shell scripts https://mise.jdx.dev/tips-and-tricks.html#shebang

The fact that mise doesn't depend on nix is both a blessing and a curse. I have less tools available and I don't have the power of a package manager, but on the flip side I don't need to deal with the idiosyncrasies of nix.

Thank you, TIL about ubi! My brain is now compiling a list of places where this will replace either a shell script or flake for my projects :).

Tasks sounds similar process-compose which is bundled into Devbox. I'll have to read up more on tasks though to see if that's an accurate assessment.

Nix is definitely a double-edged sword... One thing I like about Devbox is that it keeps Nix mostly (!) out of sight, mostly unless I want a binary from a GitHub release :).

FYI, ubi is just one of the backends. Besides many languages specific backends (cargo, go, ...), it has 3 backends that support generic packages - asdf, vfox and its own (core). Besides, the default backends are defined for many packages, so that you can let mise choose it for you.

Sounds like the Backends For Frontends pattern. Sam Newman has a nice write-up on this.