[ParetoOptimal]

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.

[karma_pharmer]

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.

[mikepurvis]

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

[Macha]

You'll also need to deal with project philosophy regarding closed source packages to get Guix as streamlined as Nix.