-
-
Notifications
You must be signed in to change notification settings - Fork 14.1k
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] Simple package paths, part 1b: Enabling the directory structure #237439
Conversation
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-06-13-nixpkgs-architecture-team-meeting-40/29087/1 |
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 am not sure you knew you can interpolate format strings in rust :)
Left diffs if you want to do it this way, but because it's mostly stylistic, I won't push it if you don't like it
@gilice I did not know that, neat! Greatly appreciated, I barely know Rust :D |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-07-13-documentation-team-meeting-notes-63/30450/1 |
Related NixOS/rfcs#109 (comment). |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-09-05-nixpkgs-architecture-team-meeting-43/32635/1 |
This introduces the `pkgs/by-name` directory as proposed by RFC 140. Included are: - The implementation to add packages defined in that directory to the top-level package scope - Contributer documentation on how to add packages to it - A GitHub Actions workflow to check the structure of it on all PRs
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.
As planned we looked at this together in today's meeting with the Nixpkgs Architecture Team (including @aakropotkin, @roberth, @DavHau, @phaer), and @fgaz, @quantenzitrone and @YorikSar.
Everything was looked at and minor documentation updates were done. Nobody had any complaints about this PR, so we'll go ahead with merging it! 🚀
Backport failed for Please cherry-pick the changes locally. git fetch origin release-23.05
git worktree add -d .worktree/backport-237439-to-release-23.05 origin/release-23.05
cd .worktree/backport-237439-to-release-23.05
git checkout -b backport-237439-to-release-23.05
ancref=$(git merge-base f67a4c3f12a72f474a4349f6255f4a0b24b805ff 77d50b03e4388f22e1f36a2621a9287a12a138be)
git cherry-pick -x $ancref..77d50b03e4388f22e1f36a2621a9287a12a138be |
Backport PR, let's make sure this one doesn't have any problems before merging it though: #253442 |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
I'm getting the following error from CI on a new PR I opened, from the
|
Thanks for the report! Opened #256756 to discuss this |
$ emacs pkgs/by-name/so/some-package/package.nix | ||
$ git add pkgs/by-name/so/some-package/package.nix |
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.
IMO this should just be default.nix to follow the previous pattern. The argument for naming it package.nix is rather weak and just creates confusion since there is no real reason to name it different.
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.
This is part of the RFC so we can't just change that, and you already started a discussion on this in NixOS/rfcs#140 (comment), let's keep it in one place
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/ci-will-soon-enforce-pkgs-by-name-for-new-packages/38098/1 |
Context
This is the first part of the implementation of the accepted RFC 140, the introduction of the new directory structure. Note that this was split up into Part 1a (#250885) and Part 1b (this PR). The second part will be done afterwards, it's draft can be found here: #211832. This is hopefully only the first of many quality-of-life improvements to Nixpkgs by the Nixpkgs Architecture Team.
Overview
This RFC introduces the new
pkgs/by-name
directory, which makes it possible to add a new top-level package by just declaring it inpkgs/by-name/${prefix}/${name}/package.nix
, wherename
is the attribute name the package should be exposed as, andprefix
is the lowercased two-letter prefix of the attribute name. This means that for a lot of packages there's no more need to find an appropriate location for the file in the loosely categorizedpkgs/
hierarchy, and no more editing of theall-packages.nix
file!Restrictions
Note however that only a subset of packages may be using this new directory structure for now, extending this is future work for the Nixpkgs Architecture Team. In particular these requirements have to be met for an attribute to be defined in
pkgs/by-name
:pkgs.python3Packages.requests
.pkgs.fetchFromGitHub
.callPackage
, not allowed are packages defined using functions likepython3Packages.buildPythonApplication
.Things done
pkgs/by-name
directory and movepkgs.hello
to itpkgs/by-name
directorynix-build -A tests.byName.nixpkgs
pkgs/by-name
breaks CI (example)nix-build -A tests.byName.tests
pkgs/by-name
directory and recommend using it for new packages