The monorepo design is unmaintainable/unscalable from a package maintainer standpoint. There’s a ton of contributor burnout, there’s no real quality control on packages
There is contributor burnout and perhaps some quality issues here and there but the monorepo isn’t the reason for that. In fact, it’d be a lot worse if we had hundreds of smaller repos instead as wide-reaching changes would become basically impossible with our current manpower.
There have been calls to fragment Nixpkgs for years but they’ve almost always been struck down because none of what was suggested would improve anything about our current maintenance issues.
to outsiders its not obvious how to report package-specific issues
You simply open an issue on GitHub. I don’t know how it could be any more clear.
I just checked and we don’t explicitly document this in CONTRIBUTING.md but I don’t think we should need to. It’s just too obvious IMO.
You actually bring up a very good point that I missed; another problem, maybe the largest problem with nix, is the culture issue.
A comment like “what do you mean nixOS doesn’t have good documentation??? we have tons of good documentation!” feels very similar to reading what you just said about “You could simply open an issue on Github, I dont know how it could be clearer”. Neither of those are a question. They’re not asking “how can we do better? (I’m sorry you, as a new user, had a hard time)”. Those comments are statements, and they say “you [person struggling to report a package-specific issue] are the problem; our system doesn’t need to change. YOU need to change”.
This culture issue has real consequences. It’s the reason Determinate Systems has a separately maintained nixpkgs-installer script, and separately maintained documentation. Its the reason I also have my own independently maintained nixpkg-installer and nixpkg-uninstaller script.
_
Maybe you haven’t had our problem because you’re really skilled and familiar with nix/github/whatever. Maybe you haven’t run into our problem because your use-case doesn’t overlap with ours. I am glad you don’t run into the problem.
But that doesn’t somehow make the problem not-a-problem.
Adopt a legacy codebase that is massive and requires EXACTLY ruby 2.6.0-rc1. On ubuntu, using rbenv, it takes a newby 30 sec to list all the available versions, and 30 sec to install ruby 2.6.0-rc1.
Even excluding versions, try searching for the extremely-commonly-needed “Core Foundation” package on search.nixos.org. I assure you the package does exist on nixpkgs, I’ve been using it for years. As a newby had to spend WEEKS looking through the source code and learning nix-lang quirks just to find it.
_
But more importantly please ignore those details and look at the bigger picture; we are on the same team. I’m not insulting or ignoring the massive accomplishments nix team has made. They (maybe you as well) are giants that have moved moutains and accomplished things I wouldve considered basically impossible. I want to help the core devs have LESS work. I want to have productive discussions about the trade-offs of federated vs monorepo, searchability, documentation improvements, installer scripts, etc.
But we can’t.
Not until the discussion starts with “I agree there’s a problem” instead of “there is no problem other than YOUR lack of skill”
Yup, figuring out how to install gcc 10 was a pain. Turns out I needed stdenvgcc10, but how would I have known that without reading like the entirety of nix pills? I don’t want to read a manual for 2 hours to figure out how to do something basic. Not to mention nix pills is SO dense that as someone who can’t learn from textbooks, its impossible.
they say “you [person struggling to report a package-specific issue] are the problem; our system doesn’t need to change. YOU need to change”.
I have not met anyone in the Nix community who’s opposed to fixing actual systematic issues. I just highly doubt that the discoverability of github issue tracking in particular is a problem that Nixpkgs is in any way responsible for.
I too wouldn’t be entirely opposed to adding i.e. a little section on how to report issues but when you’ve read half a README, then opened CONTRIBUTING.md and read through that, you really should have discovered the “issues” tab to report your, well, issue by then.
It’s the reason Determinate Systems has a separately maintained nixpkgs-installer script, and separately maintained documentation.
No. The reason they have separate instances of those is that they allow a green-field approach to things. “Move fast and break things” is great for development but you can’t do that when the entire ecosystem relies on the things you might be breaking.
The installer is a great counter example actually. If someone wanted to replace the regular installer with the detsys installer right now, the greatest opposition they’d likely face is “hey, let’s be careful to not break users’ setups, does (niche feature) still work?”.
I wouldn’t be surprised to see it replace the current official installer within the next year.
Adopt a legacy codebase that is massive and requires EXACTLY ruby 2.6.0-rc1. On ubuntu, using rbenv, it takes a newby 30 sec to list all the available versions, and 30 sec to install ruby 2.6.0-rc1.
Nixpkgs has never has supported that version and does not support using multiple versions of Nixpkgs either (not even the currently maintained branches). You can try to and it’ll probably (perhaps even likely) work but it’s not “intended” to and nobody will want to deal with issues you might encounter with that.
We regularly kick out packages that have stupid version requirements like that for a reason. Eventhough we could technically have an infinite amount of versions of any package we choose not to because it’s a maintenance burden we cannot support.
The “proper” way of handling an issue like that (I’m sorry to say but depending on some old specific version is actually an issue of the dependant) is to “vendor” the dependency; copying its expression out of the Nixpkgs tree and maintaining it yourself.
try searching for the extremely-commonly-needed “Core Framework” package on search.nixos.org
According to repology, a package under than name exists in no repository and it knows about a damn lot of repositories:
I don’t know which “Core Framework” you are referring to either.
But more importantly please ignore those details and look at the bigger picture; we are on the same team. I’m not insulting or ignoring the massive accomplishments nix team has made. They (maybe you as well) are giants that have moved moutains and accomplished things I wouldve considered basically impossible. I want to help the core devs have LESS work. I want to have productive discussions about the trade-offs of federated vs monorepo, searchability, documentation improvements, installer scripts, etc.
But we can’t.
Not until the discussion starts with “I agree there’s a problem” instead of “there is no problem other than YOUR lack of skill”
I’ve yet to see a “bigger picture”-issue described in what you wrote.
At this point I’m not sure whether we’re talking about the same Nix community anymore. We have a lot of those “big picture” issues in the Nix community and we’re aware of them. What we need the most help with is fixing them, not finding them.
I have not met anyone in the Nix community who’s opposed to fixing actual systematic issues
True, there is no one actually broadly and openly opposing change willingly or based on conviction. I think the main inhibitor to change in the nix (-pkgs / -OS) communities stems from fear. The situation is already pretty unpleasant, I think we can all agree. Contrary to that, Nix* has gained a lot of momentum in the last couple of years. Fundamental change would affect a lot of people and can easily turn the situation from unpleasant to unbearable. So people are not easily convinced to take a chance on ideas and just “try it out for a release or two” but rather die on the hills of their own personal arguments pro or against something. This ultimately leads to people blocking each other in and even though there is a will and a need to change, there is no change or it is coming very, very slowly.
My personal fear is that the shift from unpleasant to unbearable will happen not because of wrong action but because of fearful inaction.
If many people report a problem, the correct response is never “no, you’re wrong, that’s not a problem”. There’s no technical aspect to it, that is just common dececency when talking to another human.
That’s the culture issue with Nix.
It doesn’t mean an issue will never be “wont-fix” or that a issue won’t genuinely be a skill-issue. It means it’s not hard to say “I’m sorry, I disagree with adding support for that feature” or “here’s a tutorial for [skill issue]” instead of saying “no, you’re wrong, what you reported is not a problem”. When you mention editing the CONTRIBUTING.md you’re not offering help, you’re just setting up a punchline for an “[but even that wouldn’t help this IDIOT]”. There’s no sincerity, no sympathy or attempt to understand.
I don’t know how to explain it any more clearly… you’re not convincing anyone to help you on those “big issues” with words like “you really should have discovered the issues tab”.
It’s actually not. If you search for go you get the go package, but if you search for go1.21, no go package will even appear on the first page. The package you are looking for is somewhere on page 7 or 8.
I’m not sure what you mean by “searchable”?
https://search.nixos.org/packages exists and it’s generally pretty damn good.
There is contributor burnout and perhaps some quality issues here and there but the monorepo isn’t the reason for that. In fact, it’d be a lot worse if we had hundreds of smaller repos instead as wide-reaching changes would become basically impossible with our current manpower.
There have been calls to fragment Nixpkgs for years but they’ve almost always been struck down because none of what was suggested would improve anything about our current maintenance issues.
You simply open an issue on GitHub. I don’t know how it could be any more clear.
I just checked and we don’t explicitly document this in CONTRIBUTING.md but I don’t think we should need to. It’s just too obvious IMO.
https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#how-to-create-pull-requests
FlakeHub fixes none of the maintenance issues of Nixpkgs.
You actually bring up a very good point that I missed; another problem, maybe the largest problem with nix, is the culture issue.
A comment like “what do you mean nixOS doesn’t have good documentation??? we have tons of good documentation!” feels very similar to reading what you just said about “You could simply open an issue on Github, I dont know how it could be clearer”. Neither of those are a question. They’re not asking “how can we do better? (I’m sorry you, as a new user, had a hard time)”. Those comments are statements, and they say “you [person struggling to report a package-specific issue] are the problem; our system doesn’t need to change. YOU need to change”.
This culture issue has real consequences. It’s the reason Determinate Systems has a separately maintained nixpkgs-installer script, and separately maintained documentation. Its the reason I also have my own independently maintained nixpkg-installer and nixpkg-uninstaller script. _
Maybe you haven’t had our problem because you’re really skilled and familiar with nix/github/whatever. Maybe you haven’t run into our problem because your use-case doesn’t overlap with ours. I am glad you don’t run into the problem. But that doesn’t somehow make the problem not-a-problem.
Adopt a legacy codebase that is massive and requires EXACTLY ruby
2.6.0-rc1. On ubuntu, using rbenv, it takes a newby 30 sec to list all the available versions, and 30 sec to install ruby2.6.0-rc1.Try finding that version on search.nixos.org.
Even excluding versions, try searching for the extremely-commonly-needed “Core Foundation” package on search.nixos.org. I assure you the package does exist on nixpkgs, I’ve been using it for years. As a newby had to spend WEEKS looking through the source code and learning nix-lang quirks just to find it.
_
But more importantly please ignore those details and look at the bigger picture; we are on the same team. I’m not insulting or ignoring the massive accomplishments nix team has made. They (maybe you as well) are giants that have moved moutains and accomplished things I wouldve considered basically impossible. I want to help the core devs have LESS work. I want to have productive discussions about the trade-offs of federated vs monorepo, searchability, documentation improvements, installer scripts, etc.
But we can’t.
Not until the discussion starts with “I agree there’s a problem” instead of “there is no problem other than YOUR lack of skill”
Yup, figuring out how to install gcc 10 was a pain. Turns out I needed stdenvgcc10, but how would I have known that without reading like the entirety of nix pills? I don’t want to read a manual for 2 hours to figure out how to do something basic. Not to mention nix pills is SO dense that as someone who can’t learn from textbooks, its impossible.
I have not met anyone in the Nix community who’s opposed to fixing actual systematic issues. I just highly doubt that the discoverability of github issue tracking in particular is a problem that Nixpkgs is in any way responsible for.
I too wouldn’t be entirely opposed to adding i.e. a little section on how to report issues but when you’ve read half a README, then opened CONTRIBUTING.md and read through that, you really should have discovered the “issues” tab to report your, well, issue by then.
No. The reason they have separate instances of those is that they allow a green-field approach to things. “Move fast and break things” is great for development but you can’t do that when the entire ecosystem relies on the things you might be breaking.
The installer is a great counter example actually. If someone wanted to replace the regular installer with the detsys installer right now, the greatest opposition they’d likely face is “hey, let’s be careful to not break users’ setups, does (niche feature) still work?”.
I wouldn’t be surprised to see it replace the current official installer within the next year.
Nixpkgs has never has supported that version and does not support using multiple versions of Nixpkgs either (not even the currently maintained branches). You can try to and it’ll probably (perhaps even likely) work but it’s not “intended” to and nobody will want to deal with issues you might encounter with that.
We regularly kick out packages that have stupid version requirements like that for a reason. Eventhough we could technically have an infinite amount of versions of any package we choose not to because it’s a maintenance burden we cannot support.
The “proper” way of handling an issue like that (I’m sorry to say but depending on some old specific version is actually an issue of the dependant) is to “vendor” the dependency; copying its expression out of the Nixpkgs tree and maintaining it yourself.
According to repology, a package under than name exists in no repository and it knows about a damn lot of repositories:
https://repology.org/projects/?search=Core+Framework&maintainer=&category=&inrepo=¬inrepo=&repos=&families=&repos_newest=&families_newest=
I don’t know which “Core Framework” you are referring to either.
At this point I’m not sure whether we’re talking about the same Nix community anymore. We have a lot of those “big picture” issues in the Nix community and we’re aware of them. What we need the most help with is fixing them, not finding them.
True, there is no one actually broadly and openly opposing change willingly or based on conviction. I think the main inhibitor to change in the nix (-pkgs / -OS) communities stems from fear. The situation is already pretty unpleasant, I think we can all agree. Contrary to that, Nix* has gained a lot of momentum in the last couple of years. Fundamental change would affect a lot of people and can easily turn the situation from unpleasant to unbearable. So people are not easily convinced to take a chance on ideas and just “try it out for a release or two” but rather die on the hills of their own personal arguments pro or against something. This ultimately leads to people blocking each other in and even though there is a will and a need to change, there is no change or it is coming very, very slowly. My personal fear is that the shift from unpleasant to unbearable will happen not because of wrong action but because of fearful inaction.
If many people report a problem, the correct response is never “no, you’re wrong, that’s not a problem”. There’s no technical aspect to it, that is just common dececency when talking to another human.
That’s the culture issue with Nix.
It doesn’t mean an issue will never be “wont-fix” or that a issue won’t genuinely be a skill-issue. It means it’s not hard to say “I’m sorry, I disagree with adding support for that feature” or “here’s a tutorial for [skill issue]” instead of saying “no, you’re wrong, what you reported is not a problem”. When you mention editing the CONTRIBUTING.md you’re not offering help, you’re just setting up a punchline for an “[but even that wouldn’t help this IDIOT]”. There’s no sincerity, no sympathy or attempt to understand.
I don’t know how to explain it any more clearly… you’re not convincing anyone to help you on those “big issues” with words like “you really should have discovered the issues tab”.
It’s actually not. If you search for
goyou get the go package, but if you search forgo 1.21, no go package will even appear on the first page. The package you are looking for is somewhere on page 7 or 8.Indeed, that looks like a bug. The version field is there but it doesn’t appear to be searched.
Could you open an issue on https://github.com/NixOS/nixos-search?