4 ms·

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

by jdxcode 2y ago

lifty 2y ago
thank you!
yawaramin 2y ago
Have you tried devenv? What do you think?
- jdxcode 2y ago
  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.
  - max-privatevoid 2y ago
    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.
  - yawaramin 2y ago
    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-security-incident-12604/ https://daniel.haxx.se/blog/2024/03/08/the-apple-curl-securi...
    - jdxcode 2y ago
      system updates causing breakages with mise tools would be news to me
  - Nullabillity 2y ago
    > 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.
    - jdxcode 2y ago
      > And where are those mystery meat binaries supposed to come from? the vendor
      - Nullabillity 2y ago
        Right, because that never goes wrong.[0,1] [0]: https://news.ycombinator.com/item?id=42351722 https://news.ycombinator.com/item?id=42351722 [1]: https://tukaani.org/xz-backdoor/ https://tukaani.org/xz-backdoor/
        goku12 2y ago
        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.
        Nullabillity 2y ago
        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.
  - nixosbestos 2y ago
    I don't get it. mise and nix binaries both go somewhere that gets added to PATH.
  - Quiark 2y ago
    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.
  - JamesSwift 2y ago
    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).
aiono 2y ago
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?
- syhol 2y ago
  > 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 started writing mise in a bout of frustration after trying to use nix

lifty 2y ago

thank you!

yawaramin 2y ago

Have you tried devenv? What do you think?

jdxcode 2y ago
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.
- max-privatevoid 2y ago
  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.
- yawaramin 2y ago
  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-security-incident-12604/ https://daniel.haxx.se/blog/2024/03/08/the-apple-curl-securi...
  - jdxcode 2y ago
    system updates causing breakages with mise tools would be news to me
- Nullabillity 2y ago
  > 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.
  - jdxcode 2y ago
    > And where are those mystery meat binaries supposed to come from? the vendor
    - Nullabillity 2y ago
      Right, because that never goes wrong.[0,1] [0]: https://news.ycombinator.com/item?id=42351722 https://news.ycombinator.com/item?id=42351722 [1]: https://tukaani.org/xz-backdoor/ https://tukaani.org/xz-backdoor/
      - goku12 2y ago
        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.
        Nullabillity 2y ago
        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.
- nixosbestos 2y ago
  I don't get it. mise and nix binaries both go somewhere that gets added to PATH.
- Quiark 2y ago
  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.
- JamesSwift 2y ago
  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).

aiono 2y ago

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?

syhol 2y ago
> 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.