NixOS / ofborg

for example, NixOS/nixpkgs#138049
python3Packages.surepy is mentioned in the commit message but not automatically built by ofborg

i'm not familiar with ofborg code base but looks like

ofborg/ofborg/src/tasks/eval/nixpkgs.rs

Line 315 in 517a32a

.filter(|pkg| possibly_touched_packages.contains(&pkg))

is causing the issue

I think ofborg/src/outpaths.nix evaluates changed paths to either python38Packages.* or python39Packages.*, and python3Packages.* gets filtered out because it doesn't contain it

if we apply

diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix
index d13066e27f3..f748a88a5b5 100644
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -14052,6 +14052,11 @@ with pkgs;
   # When switching these sets, please update docs at ../../doc/languages-frameworks/python.md
   python2 = python27;
   python3 = python39;
+
+  # pythonPackages further below, but assigned here because they need to be in sync
+  python2Packages = python27Packages;
+  python3Packages = python39Packages;
+
   pypy = pypy2;
   pypy2 = pypy27;
   pypy3 = pypy38;
@@ -14093,10 +14098,6 @@ with pkgs;
     x11Support = true;
   };
 
-  # pythonPackages further below, but assigned here because they need to be in sync
-  python2Packages = python2.pkgs;
-  python3Packages = python3.pkgs;
-
   pythonInterpreters = callPackage ./../development/interpreters/python { };
   inherit (pythonInterpreters) python27 python37 python38 python39 python310 python311 python3Minimal pypy27 pypy38 pypy37 rustpython;

to nixpkgs

./maintainers/scripts/rebuild-amount.sh --print HEAD
then shows them like this

python3Packages.aadict.x86_64-darwin                                                      /nix/store/n79wdn1fyggr6gckbaabrlscd21hnq0d-python3.9-aadict-0.2.3
python3Packages.aadict.x86_64-linux                                                       /nix/store/vmf21dggnzwvdnm18imh8rdx4zk6wlkn-python3.9-aadict-0.2.3
python3Packages.aafigure.x86_64-darwin                                                    /nix/store/1qg83k9av56mi9y7jz5ri39rmpyjjklw-python3.9-aafigure-0.6
python3Packages.aafigure.x86_64-linux                                                     /nix/store/kmawq9a4kk9m2cixzp3kd7xnijwd5i80-python3.9-aafigure-0.6
python3Packages.abodepy.x86_64-darwin                                                     /nix/store/dh097lw54jp7ajnp67w6i97sbv63al3c-python3.9-abodepy-1.2.2
python3Packages.abodepy.x86_64-linux                                                      /nix/store/diqymzkczjk26q3mmyg1kal87vi63s9r-python3.9-abodepy-1.2.2
python3Packages.absl-py.x86_64-darwin                                                     /nix/store/sdy43z1j3pg1vhz5kw1glcn2pw9vb0af-python3.9-absl-py-1.0.0
python3Packages.absl-py.x86_64-linux                                                      /nix/store/dagbzxd9qccmjykhz1x0wayzadlc96rp-python3.9-absl-py-1.0.0
python3Packages.accuweather.x86_64-darwin                                                 /nix/store/jxsfb563scgihwd7a246hfl2mm55xw5r-python3.9-accuweather-0.3.0
python3Packages.accuweather.x86_64-linux                                                  /nix/store/y9igwhna04r8ijx2z7mvrygax10m204m-python3.9-accuweather-0.3.0
python3Packages.acebinf.x86_64-darwin                                                     /nix/store/8vcma9x9sxpmj2cnm8fb4yqa5pgqs74x-python3.9-ACEBinf-1.0.2

Dumb question, and I might not even have the details right: why does ofborg evaluate the full release package set and then filter that down to the mentioned attrpaths, instead of starting with the mentioned attrpaths and evaluating only their outpaths? I would think that would solve this issue and also be a little faster.

python3Packages are not built automatically