-
-
Notifications
You must be signed in to change notification settings - Fork 14.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC 140 2a] pkgs/by-name
: Enforce for new packages
#275539
Conversation
c53ec7b
to
9d746df
Compare
1c31376
to
41b1926
Compare
This PR is now theoretically ready, but since the changes got a bit big, I split off everything not directly related to this PR into #278805, which should be merged first. |
41b1926
to
6ff113c
Compare
pkgs/by-name/README.md
Outdated
Packages found in the named-based structure do not need to be explicitly added to the | ||
Packages found in the name-based structure must not be added to the | ||
`top-level/all-packages.nix` file unless they require overriding the default value | ||
of an implicit attribute (see below). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is still better to lead with the positive part. Something like
Packages found in the name-based structure are automatically included, without needing to be added in a file like
all-packages.nix
. They must only occur in file if they require overriding the default value of an implicit attribute (see below).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed the wording a little bit, but this is essentially applied now :)
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2024-01-09-nixpkgs-architecture-team-meeting-47/38037/1 |
6ff113c
to
6e192d8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took a thorough look. The tests are quite clear. Nice work. I don't have any code related comments, just copy-editing. Might also run a RFC101 formatter over these Nix files just for giggles.
if let Some(path) = &call_package_path { | ||
format!("./{}", path.display()) | ||
} else { | ||
"...".into() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For my notes: pkgs/test/nixpkgs-check-by-name/tests/new-package-non-by-name/expected is the test of this.
// This is a bit of an odd case: We don't even _know_ whether this attribute | ||
// would qualify for using pkgs/by-name. We can either: | ||
// - Assume it's not using pkgs/by-name, which has the problem that if a | ||
// package evaluation gets broken temporarily, the fix can remove it from | ||
// pkgs/by-name again | ||
// - Assume it's using pkgs/by-name already, which has the problem that if a | ||
// package evaluation gets broken temporarily, fixing it requires a move to | ||
// pkgs/by-name |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Future ratchets might try to drive this number down, I might imagine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yeah, I thought about implementing an eval-successful ratchet, but I think this should be a future PR. Then also it's also not pkgs/by-name
-specific anymore and the tool could use a rename.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One only needs to look at the list of things detected by NixpkgsProblems to realize we've backed ourselves into a damn fine nixpkgs linter framework. 🚀
In a future commit this will be extended
Not that important, but nice. Also adds a nice test case show-casing the two current ratchet checks at once.
This was an oversight in NixOS#275539 not accounted for, which would've failed in CI
Now that nixos-unstable contains the latest fixes, here's the final follow-up PR: #281835 which starts enabling the enforcement! |
This was an oversight in NixOS/nixpkgs#275539 not accounted for, which would've failed in CI
Note
An open call for the final review and merge was held on 2024-01-15, see #275539 (comment)
Context
This is part of the effort to implement RFC 140, aka
pkgs/by-name
. While previous PRs already enabled users to define packages usingpkgs/by-name
, there's still thousands of packages still usingall-packages.nix
, and new ones added every day.This PR is part of the RFC 140 migration plan, building on top of #272395 and #274591.
This work is sponsored by Antithesis and Tweag ✨
Changes
This PR prevents new packages using
pkgs.callPackage
from being defined not inpkgs/by-name
. Instead thepkgs/by-name
directory has to be used instead. This the A-side of Part 2 of the RFC.This doesn't affect packages defined using alternate
callPackage
's likelibsForQt5.callPackage
orcallPackages
, whichpkgs/by-name
cannot handle (yet?).Note
The effects of this PR will only be seen once the nixos-unstable channel updates, since its pre-built version of the tooling is used for CI.
Things done
callPackage
but not usingpkgs/by-name
throw an errorpkgs/by-name
throws an errorcallPackage
doesn't give an error.Add a 👍 reaction to pull requests you find important.