Can one provide reproducible dev environment that uses a tool that is not yet in mise registry? Or does one need to wait it to be added into the registry? Also if I want to provide a python runtime that is compiled slightly differently can I do that? Or does it have to be distributed as a precompiled binary?
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.
mise is for the 90% of developers that just want things to be fast and work and don't care about the nuts and bolts.
What you are really butting up against is that the nix store is a bit of a split-brained runtime environment. Its not easy to e.g. `gem install` to your system while running a nix-managed ruby. This has nothing to do with the binaries (well... sometimes it does because nix will patch paths to point to the readonly store, but again thats orthogonal).
[1] https://daniel.haxx.se/blog/2024/03/08/the-apple-curl-securi...
And where are those mystery meat binaries supposed to come from? What do you do if the provided binaries aren't enough? (Wrong version, wrong build flags, what you want isn't even packaged, don't support your platform, etc, etc, etc.)
Binary package managers have been tried over and over, and never work out well.
> gives your system a "split-brain" problem where you have the "nix world" and the "macos (or whatever) world".
Yeah no, that's inherent as soon as you bring in any kind of secondary package manager. Including pyenv or mise or whatever else.
the vendor
While skipping the released tarballs wouldn't have prevented the problem entirely, it would have made it much harder to hide.
Ant was by far the most stressful. I had to cyberstalk James Duncan Davidson to understand what he was thinking. The mental model for the tool wasn’t in the docs. It was in forum posts spread across three+ different websites. And it was slightly insane. First writer wins broke everyone’s brains across three jobs before someone helped me kill it and replace it with something else.
It’s also a cornerstone of my thesis: never trust software someone says they wrote on an airplane. That’s not enough time to create a good solution, and any decision you make while experiencing altitude sickness is sketchy. (Prior to 2010, airline passengers were experiencing 8000 ft atmosphere on every flight. One of the selling points of the 787 was 5000 ft equivalent pressure)
Could you elaborate on what the debate is? Haven't heard of this before!
devenv, a Nix+direnv-based solution, has a pretty cool task runner thing, plus service management.
> I don't understand why there are any other alternatives still being developed.
I love Nix and I believe it's a great choice for many teams, for the same use cases as mise. Nix's paradigm is the future. But Nix's defects are also real and obvious enough if you use it for long. I can understand why someone might see value in trying a fresh new effort, or an approach that asks less commitment.
The task runner part is also solved in Nix. See
https://github.com/Platonic-Systems/process-compose-flake
and
$ nix-shell -p nodejs_20
[nix-shell:~]$ node --version
v20.18.1
Example 1:
updating dependencies that are outside of nixpkgs is not a one command ordeal. Especially if you’re doing something like updating the commit shape of a packaged release you’re targeting. I think there’s no reason they couldn’t have some clean way of writing rules automate update non-nixpkgs (why do I have to do this dumb nix-prefetch-url thing myself to compute some hash?).
If I am selling nix to end users as a system package management solution I’m comparing it to tools like brew. As long as you stay in nixpkgs it’s fine - but as soon as you’re out of that (which almost everyone is going to have at least o e package that is either not in nixpkgs or they can’t use the nixpkgs one for some reason) maintenance is no longer as simple as brew update / nix flake update.
Example 2:
Nix just doesn’t have very good debugging tools. It reminds me a lot of terraform. Yes there is an REPL but the simple task of breakpointing and seeing the value of data structures is not really straightforward in nix. If you want to it language to be approachable you need to make it dead simple to immediately be able to spit out its state in a way that an engineer knows how to work with it. I would not say the process of doing so in Nix is dead simple
While we're on the subject, I can assure you, Nix is far, far from groundbreaking tech.