zlacker

[return to "A leadership crisis in the Nix community"]
1. aredox+q8[view] [source] 2024-04-29 15:35:20
>>elikog+(OP)
The main reason for the persistence of Nix despite its warts and general mess is just "first-mover advantage": it was the first, therefore it has more libraries/packages/development of the ecosystem than the alternatives.

Stop being lazy, go back to engineering first principles and it makes little sense to stay with Nix. Guix or any rewrite as a library in a well-developed language* makes more sense.

*For example, why are Haskellians using Nix so much instead of integrating its concepts into their own tooling?

◧◩
2. Pareto+O9[view] [source] 2024-04-29 15:42:44
>>aredox+q8
Cabal has had nix-style local builds since 2016:

https://blog.ezyang.com/2016/05/announcing-cabal-new-build-n...

https://cabal.readthedocs.io/en/2.0/nix-local-build-overview...

Also cabal isn't positioned to be a system level package manager. Haskell programmers are the type to want both their application builds and system dependencies to be reproducible and predictable.

> Stop being lazy, go back to engineering first principles and it makes little sense to stay with Nix. Guix or any rewrite as a library in a well-developed language* makes more sense.

Getting Guix packages to be as complete as nixpkgs isn't a matter of laziness though. One person wouldn't be able to do it no matter how disciplined they were.

◧◩◪
3. karma_+gy2[view] [source] 2024-04-30 09:35:33
>>Pareto+O9
Cabal has had nix-style local builds since 2016:

That's a bug not a feature.

Every language these days is trying to force you to use its own badly-implemented imitation of Nix. Just look at what cargo does with the target/ directory and wonky "build fingerprints".

It's madness.

◧◩◪◨
4. mikepu+TT7[view] [source] 2024-05-01 21:14:57
>>karma_+gy2
It can also make those systems considerably harder to integrate into Nix itself. There almost need to be some language-neutral standards developed for how to manage inputs and lockfiles in such a way that more of this tooling can be shared at the developer/workspace level while also hoisting the same metadata up into systems like Nix and Bazel.

As it is, the rust-in-Nix and bazel-in-Nix stories are both pretty terrible, while the Python one is actually not too bad: https://github.com/nix-community/poetry2nix (barring these 4000 lines of horrible hacks: https://github.com/nix-community/poetry2nix/blob/master/over... and these 27000 lines of telling Nix which Python buildsystem every package ever happens to use: https://github.com/nix-community/poetry2nix/blob/master/over...)

[go to top]