Hacker News Reader

Comment by jdxcode | Hacker News Reader

I started writing mise in a bout of frustration after trying to use nix

Nix UX really sucks I agree with that. But it has a very robust core model and is reproducible from the bottom up. Tools like asdf, renv etc. just provide you some binaries. If you need some system libraries installed they don't help with that for example.

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?

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

Have you tried devenv? What do you think?

I think the entire concept of nix is a broken model not fixable by docs and better DX. Precompiled, portable binaries are the way to go which is what mise is built on. Trying to maintain this separate build chain where everything is compiled in a sandbox gives your system a "split-brain" problem where you have the "nix world" and the "macos (or whatever) world". Ultimately, this just causes problems. Of course I'm ignoring NixOS but that's a sledgehammer for this supposed "problem" nix is trying to solve in the first place.

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.

Nothing in nix says you have to compile something from source. Just that the resulting artifact needs to be reproducible hermetically. You can download any random blob from the internet as a nix derivation, as long as you tell nix what the resulting hash should be after you download it. Sure, it might have unmet runtime dependencies, but thats orthogonal.

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

Don't you kinda need to separate the worlds to avoid borking your system when you update? Eg macOS decides to ship some customizations in its curl,[1] and now you need your own curl because Apple's customization is breaking your project?

[1] https://daniel.haxx.se/blog/2024/03/08/the-apple-curl-securi...

system updates causing breakages with mise tools would be news to me

I've been using nixpkgs on macos (and without brew) for 3 years now and not sure what kind of split brain problem you're talking about? I also have no idea about the problems with multiple anaconda and other python builds complain about.

I don't get it. mise and nix binaries both go somewhere that gets added to PATH.

> Precompiled, portable binaries are the way to go which is what mise is built on.

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.

> And where are those mystery meat binaries supposed to come from?

the vendor

Right, because that never goes wrong.[0,1]

[0]: https://news.ycombinator.com/item?id=42351722

[1]: https://tukaani.org/xz-backdoor/

The xz example does not support your case. Not only was every downstream build infected until it was discovered, it also needed a distro-specific modification (to openssh in Debian and Fedora, IIRC) to work at all.

The xz backdoor relied on a discrepancy between the development repository and the released (source) artifact.

While skipping the released tarballs wouldn't have prevented the problem entirely, it would have made it much harder to hide.

If only they were actually portable. As it stands, mise is just another half-solution, and you can't solve the other half of the problem by ignoring it.

thank you!

Reply on news.ycombinator.com