pkgs/README: Document commit prefixes & automatic CI builds

[doronbehar]

I found myself explaining these details very often through out my time with Nixpkgs, and it always felt a bit weird for me that these are document in a different repository. So I decided to slightly copy that content to Nixpkgs, with a refresh set of examples.

I'm asking for a review from a few people who were involved in #400934, as this PR should be tangent but still may be slightly related:

• @infinisil
• @drupol
• @pbsds
• @MattSturgeon

[wolfgangwalther]

These guidelines are specific to pkgs/ - they don't apply to all the other parts of nixpkgs. Thus, I think the right place to put them is in the specific conventions for this subfolder at https://github.com/NixOS/nixpkgs/tree/master/pkgs#commit-conventions.

[wolfgangwalther]

Note the following:

nix-repl> python3Packages.recurseForDerivations
false

nix-repl> python312Packages.recurseForDerivations
true

nix-repl> python313Packages.recurseForDerivations
true

So this explanation doesn't quite line up, yet.

[doronbehar]

Hmm this is indeed confusing. The ofborg README also doesn't give as examples python3Packages, but here's an example were ofborg created (as always) a PR with python3Packages in the prefix and ofborg did (at least attempted) to build the packages:

• python3Packages.bokeh-sampledata: 2024.2 -> 2025.0 #423326

See also:

• all-packages.nix: pythonXPackages point to pythonXXPackages #165994

Let's ask @Artturin for help specifically on this.

[pbsds]

aliases like python3Packages.foobar didn't use to work before the ofborg migration necessitating e.g. python313Packages.foobar, but now it does. More context in NixOS/ofborg#577. Since that issue was closed r-ryantm was switched to the python3Packages alias which avoids a lot of duplicate PRs.

[doronbehar]

Thanks @pbsds for commenting. I sort of figured that out, but it's nice to link that issue too. The questions making this review conversation still open, are: What is the parameter that dictates if ofborg will build an attribute or not? Is it whether they are recursed to or not and python3Packages is an exception hard-coded in ofborg's code? Or is it due to something more subtle the way we define these attribute sets in all-packages.nix?

[wolfgangwalther]

I think by now ofborg just builds what it gets. You tell it to build a.b.c: init and it will build a.b.c, no questions asked. That's because it doesn't do any eval step anymore, that could do any of the recursion parts.

[doronbehar]

It might be true nowadays indeed. Let's wait and see:

• python3.pkgs.units-llnl: set FOO = BAR #431753

[doronbehar]

Indeed ofborg has no difference between python3.pkgs and python3Packages and the rest! I tested also a gotify-server.ui: commit, where gotify-server.ui is completely not recursed into by Hydra, and it built it too.

[wolfgangwalther]

The python docs seem to give outdated advice on this python3Packages thing:

nixpkgs/doc/languages-frameworks/python.section.md

Lines 2127 to 2131 in daa2ab8

	* The current default version of python should be included
	in commit messages to enable automatic builds by ofborg.
	For example `python313Packages.numpy: 1.11 -> 1.12` should be used rather
	than `python3Packages.numpy: 1.11 -> 1.12`.
	Note that `pythonPackages` is an alias for `python27Packages`.

I guess we should update these, too.

[doronbehar]

Thanks for noticing that too @wolfgangwalther . PR is at:

• doc/python: fix commit prefix instructions (refer to pkgs/README) #433585

hard blockers had been addressed, although some questions still remain.

[doronbehar]

Thanks for your reviews, the whole recursedInto subject indeed is no longer relevant and the paragraph before the table with the example is much more simple now.

[wolfgangwalther]

Since this describes what is already fact and is "just" an updated documentation of what is available in the ofborg repo, I consider this uncontroversial enough in principle to not wait for more community feedback.

[drupol]

Please ignore my previous comment.