5 ms·

This is already a solved problem with Nix shell (except the task runner part). I don't understand why there are any other alternatives still being developed. Ni

by aiono 2y ago

This is already a solved problem with Nix shell (except the task runner part). I don't understand why there are any other alternatives still being developed. Nix supports more packages than any other solution, it's battle tested and cross platform (didn't try on Windows but on Mac OS it works fine). And it's more reproducible than any other package manager.

bloopernova 2y ago
Because some people may not want nix. Mise is, in my experience, much easier to get into and start using.
jdxcode 2y ago
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/
- 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.
lijok 2y ago
Because Nix has dogshit UX and the team seem to be completely oblivious to it regardless of how many times it's brought up.
- max-privatevoid 2y ago
  Well, "dogshit UX" isn't exactly actionable, is it?
  - lijok 2y ago
    Oh it absolutely is !
    - max-privatevoid 2y ago
      Care to give some examples?
      - lijok 2y ago
        Use it as a signal to start an investigation into how many agree with that sentiment, try to measure the resulting adoption dropoff, and use those stats to push for a UX redesign.
        Valodim 2y ago
        This is a pretty ignorant stance. It implies that the issues would somehow be easy to address if they were just acknowledged. Are you aware of the efforts that have been put into this so far? Have you considered that achieving the vague improvements you are asking for, working on a groundbreaking technology while holding together a rapidly growing community, is just really hard?
        lijok 2y ago
        Can you clarify how you arrived at the conclusion that I was implying fixing the UX is easy, or where you saw me asking for "vague improvements"? While we're on the subject, I can assure you, Nix is far, far from groundbreaking tech.
nextaccountic 2y ago
I really want nix to succeed, but it has terrible UX and documentation. It also doesn't help that the community is still fighting over whether flakes should be a thing.
- hinkley 2y ago
  Every time I’ve used a declarative system at work I either eventually become one of the experts and we all have lines outside our door of people who just don’t get it, or I replace it with something imperative so we can all get some fucking peace. 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)
  - ericyd 2y ago
    Is it a frequent experience for you to have to disregard a piece of otherwise appealing software because the developer claims to have written it on a plane?
    - hinkley 2y ago
      It’s not that common for one to stick. But it is common for people to bitch about using them a lot more than average for tools.
  - SOLAR_FIELDS 2y ago
    That… was not the thesis I was expecting
- crakhamster01 2y ago
klysm 2y ago
Docs are terrible, writing new packages is difficult, etc. It may be the right technical direction but the execution is lackluster
- ghthor 2y ago
  Reading nixpkgs is pretty amazing info, better then any docs. But I actually think the docs are pretty fantastic. The manual is solid, the CLI help text is pretty excellent. I don’t get when people say the docs are bad.
  - klysm 2y ago
    I’ve tried to use nixos for my homelab and ran into undocumented errors
pxc 2y ago
> This is already a solved problem with Nix shell (except the task runner part). 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.
srid 2y ago
> This is already a solved problem with Nix shell (except the task runner part) The task runner part is also solved in Nix. See https://github.com/Platonic-Systems/process-compose-flake https://github.com/Platonic-Systems/process-compose-flake and https://github.com/juspay/services-flake https://github.com/juspay/services-flake

by aiono 2y ago

bloopernova 2y ago

Because some people may not want nix. Mise is, in my experience, much easier to get into and start using.

jdxcode 2y ago

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

lijok 2y ago

Because Nix has dogshit UX and the team seem to be completely oblivious to it regardless of how many times it's brought up.

max-privatevoid 2y ago
Well, "dogshit UX" isn't exactly actionable, is it?
- lijok 2y ago
  Oh it absolutely is !
  - max-privatevoid 2y ago
    Care to give some examples?
    - lijok 2y ago
      Use it as a signal to start an investigation into how many agree with that sentiment, try to measure the resulting adoption dropoff, and use those stats to push for a UX redesign.
      - Valodim 2y ago
        This is a pretty ignorant stance. It implies that the issues would somehow be easy to address if they were just acknowledged. Are you aware of the efforts that have been put into this so far? Have you considered that achieving the vague improvements you are asking for, working on a groundbreaking technology while holding together a rapidly growing community, is just really hard?
        lijok 2y ago
        Can you clarify how you arrived at the conclusion that I was implying fixing the UX is easy, or where you saw me asking for "vague improvements"? While we're on the subject, I can assure you, Nix is far, far from groundbreaking tech.

nextaccountic 2y ago

I really want nix to succeed, but it has terrible UX and documentation. It also doesn't help that the community is still fighting over whether flakes should be a thing.

hinkley 2y ago
Every time I’ve used a declarative system at work I either eventually become one of the experts and we all have lines outside our door of people who just don’t get it, or I replace it with something imperative so we can all get some fucking peace. 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)
- ericyd 2y ago
  Is it a frequent experience for you to have to disregard a piece of otherwise appealing software because the developer claims to have written it on a plane?
  - hinkley 2y ago
    It’s not that common for one to stick. But it is common for people to bitch about using them a lot more than average for tools.
- SOLAR_FIELDS 2y ago
  That… was not the thesis I was expecting
crakhamster01 2y ago

klysm 2y ago

Docs are terrible, writing new packages is difficult, etc. It may be the right technical direction but the execution is lackluster

ghthor 2y ago
Reading nixpkgs is pretty amazing info, better then any docs. But I actually think the docs are pretty fantastic. The manual is solid, the CLI help text is pretty excellent. I don’t get when people say the docs are bad.
- klysm 2y ago
  I’ve tried to use nixos for my homelab and ran into undocumented errors

pxc 2y ago

> This is already a solved problem with Nix shell (except the task runner part). 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.

srid 2y ago

> This is already a solved problem with Nix shell (except the task runner part) The task runner part is also solved in Nix. See https://github.com/Platonic-Systems/process-compose-flake https://github.com/Platonic-Systems/process-compose-flake and https://github.com/juspay/services-flake https://github.com/juspay/services-flake