Each language ecosystem appears to take on its own quirks when it gets nixified, and aside from reading the code in nixpkgs it’s really unclear where a person should go when they want to get up to date with those quirks.
Once I know nix better I intend to write a number of blog posts for the languages I use (“Python on Nix”, “Nim on Nix”, etc), but it feels like it’ll be a while before I’m confident enough to do that.
In the meantime, I wonder if something can be done to ensure that the right people cross paths. It’s nice to be part of the Nix community, but maybe it would be more helpful to be part of the Nix-Erlang community. Seems like language-focused subforums (subfora?) might help address this as well:
Erlang is on my list. If there ever emerges a place for that community to gather, I’ll probably be lurking there in the future.
Good luck with that packages wrapper. A kind soul recently taught me a lesson about the python one (thanks @anund), so it would seem that making mistakes in public and then making noise on discourse about it is a decent strategy (even though it doesn’t feel quite right).
The documentation about porting Nixpkgs and Nix to a new platform is absent. I tried to figure it out once, but it turns out that we could only find (fragmented) information inside PRs and commits. This is a pity as Nixpkgs is advertised for its ability of cross-platform build and cross-compilation.
If you’re willing to share something more specific about the bureaucracy you encountered, I think that would be valuable, as yours was a contribution that did make it into other distros, so it could be interesting to see why it didn’t make it into nixpkgs.
From a real basic perspective, most “starting to use nix” guides do not layout or format derivations in the same style as nixpkgs (callPackage is hidden inside all-packages.nix)
This leads to the problem that you end up calling ugly code like: nix-build -E 'with {}…"
Once you realise you can put the callPackage in default.nix, the code is explicity not compatible with nixpkgs, you can’t just copy-paste it in to it. It nix3 /fakes intheory fixes this…nixpkgs isn’t layed out like that
WHY IS all-packages.nix 41k LINES OF CODE??? WHY is it not organized based on the folder structure??? WHY NIL AND RNIX-LSP FREEZE EMACS??
meta.maintainers is missing from core features, and modules, because most core features are heavily modified derivations they seem to be treated differently. A few times I’ve opened up a Issue and didn’t know who to @. for example the “default” less implementation is broken, it fails on some files because “strings” is missing, I had no clue why, after a lot of digging I figured out why, I’ll leave this as an exercise to prove my point, hint, the official maintainer hasn’t made any commits since 2016, and it’s not the stand linux less command.
nix 3 needs to be enabled, but give a warning, flakes should just work.
I think there’s a lack of “leadership” or clear defined hierarchy in the sense that no one is providing a direction or holding maintainers to some sort of standard, which is why it’s simultaneously impossible to get things PR’d and also why stupid decisions like hard-coding a badly maintained less package got merged in to the core definition of nixos.
secret management sucks, especially for builders.
Its hard to communicate the difference between nixpkgs the repo and nixpkgs the package set pkgs = import <nixpkgs> {}, for example nixos modules are in nixpkgs, but not the “pkgs” output.
I would propose that:
all-packages.nix is split out in to their respective folders.
each folder should have a meta.maintainers definition.
modules should also have a maintainers definition somewhere.
the maintainer reviews PR for their respcetiev folder or delagates to trusted maintainers in the respective subfolder.
A linter needs to check for missing maintainers list, many Linux kernels don’t have them for example.
One thing I do love about nixpkgs is just the share amount of pkgs available, it’s so much easier to just use overrideAttr to bump old packages than try and deal with the likes of aur. And I would hate if that changed tho.
That’s beautiful Hopefully eventually there’s also a solution to variants/arguments/aliases, since that’s what I find most of my reason to actually readall-packages.nix to be. A lot of hidden implementation lives in that file.
Still, this will be an incredible improvement, an 81% reduction sounds enough for editors and language servers to actually open the file.
I guess that changes the hierarchy of management I was suggesting, but I definitely support the improvements otherwise, I’m happily surprised that package.nix is being used, I was considering the same thing when I write my own ad-hoc stuff
I don’t think anything not mentioned in this thread already.
Nixpkgs seems to try and solve for everyone which makes getting changes in a bit harder via committee.
I’ve noticed the other alternatives (spack and guix) have a bit more of a BDFL approach which makes some large issues easier. (democracy vs dictatorship lol).
tbh, I just didn’t have the personal time to devote needed to steer it all the way through.
I am impressed with everyone who puts effort into the RFC, comments, comments, comments, issues and finally to the implementation.
Hopefully eventually there’s also a solution to variants/arguments/aliases, since that’s what I find most of my reason to actually read