Any idea why it was done the way it was done before?

Any idea why it was done the way it was done before?

The doCheck guard is added in #327264, saying it would be "useful when running the tests separately in passthru.tests."

I doubt guarding the flags this way would be as effective as intended, as neither checkPhase (installCheckPhase) nor checkInputs (installCheckInputs) are guarded.

To achieve the effect, wouldn't we need to guard this on separateChecks somehow?

Edit: Ah, #272177 wasn't even merged. So it seems like the guards will only be useful once that's done, right?

To achieve the effect, wouldn't we need to guard this on separateChecks somehow?

The original PR was an initial effort for #272177, but it was unfortunately closed due to author burnout.

It is more practical to re-work the guard if someone wants to pick up the automatic-passthru-test work.

Edit: Ah, #272177 wasn't even merged. So it seems like the guards will only be useful once that's done, right?

I think so.

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 376060

x86_64-linux

Some Python packages, especially scientific ones, have expensive tests.
Their compilation time is also usually expensive because they are written in C++, Rust, etc.
Therefore, such packages already separate their tests into passthru.tests, even if separateChecks is not implemented.

I doubt guarding the flags this way would be as effective as intended, as neither checkPhase (installCheckPhase) nor checkInputs (installCheckInputs) are guarded.

In python packages, checkPhase is provided by pytestCheckHook in most cases, so it is unlikely to be changed.
While nativeCheckInputs may be worth blocking, I think we already block the attributes we most often change to make tests green.

However, I do not intend to prevent our ideals with these hacks, so I believe we could remove it if necessary.

Therefore, such packages already separate their tests into passthru.tests, even if separateChecks is not implemented.

I understand this as we add such guards as a shorthand to "move" the attributes to passthru.tests so we could write, e.g., passthru.tests.check = self.overridePythonAttrs { doCheck = true; }; without having to manually place all the check-related attributes under the definition of passthru.tests.check. Is that correct?

If so, why do people not just define the check-related attributes under the package test definition (e.g., the passthru.tests.check above)?

I understand this as we add such guards as a shorthand to "move" the attributes to passthru.tests so we could write, e.g., passthru.tests.check = self.overridePythonAttrs { doCheck = true; }; without having to manually place all the check-related attributes under the definition of passthru.tests.check. Is that correct?

Yes, absolutely.

If so, why do people not just define the check-related attributes under the package test definition (e.g., the passthru.tests.check above)?

I guess they didn't think to guard the flags, because it was also a known hack to avoid circular imports.
I introduced this guard to avoid checkArgs, an attribute proposed in #272177, but I think it is a good idea to define flags in passthru.tests.

I guess they didn't think to guard the flags because it was also a known hack to avoid circular imports.

This means we must transit all the packages currently using such a hack before merging this PR to avoid breakage.

As the tree-wide transition is unavoidable (even if the total number of affected packages is not necessarily large), I would prefer resuming (re-implementing) #272177 before the migration to make the effort more meaningful.

As for the checkArgs, I prefer an extension-style passthru.overridePythonCheck similar to buildGoModule's overrideModAttrs.

Here's a worked prototype: staging...ShamrockLee:build-python-passthru-check
It depends on #376372 merging and going from master to staging, with three commits that

• pass the check-related args directly
• implement optional tests.python-check
• transit python3Packages.pygments to use tests.python-check

@natsukium @wolfgangwalther Do you think this is a good idea, or should we proceed with the transition directly?

I guess they didn't think to guard the flags, because it was also a known hack to avoid circular imports.

Performing checks separately avoids circular dependency for test cases, but how does it related to guarding the flags? The flags are mostly plain strings, and has no effect when doCheck = false.

In addition, if the flags cause circular dependency, the evaluation would fail. If the evaluation work, it should be safe to merge this PR.

These packages, found with the following find command plus manual filtering, specifies doCheck = false due to cyclic/circular dependencies, and also specifies one of the previously-guarded flags attributes. I think this is enough to check if this PR could be merged without tree-wide package migration.

find pkgs/development/python-modules -type f -name "*.nix" \
  -exec grep -q "doCheck = false" {} \; \
  -exec grep -q "\([Cc]ircular\|[Cc]yclic\)" {} \; \
  -exec grep -q '\(disabledTest\|pytestFlags\|unittestFlags\)' {} \; \
  -print

@ofborg build python3Packages.pygments
@ofborg build python3Packages.torchmetrics
@ofborg build python3Packages.mlflow
@ofborg build python3Packages.libcst
@ofborg build python3Packages.build
@ofborg build python3Packages.opentelemetry-sdk

@wolfgangwalther, are you still approving this change?

@ofborg build python3Packages.pygments
@ofborg build python3Packages.torchmetrics
@ofborg build python3Packages.mlflow
@ofborg build python3Packages.libcst
@ofborg build python3Packages.build
@ofborg build python3Packages.opentelemetry-sdk

Thanks for working on these things!

@mweinelt Thank you for reviewing and merging!

Could you also help take a look at other PRs on the tracking issue

• Tracking: Python packages' overrideAttrs overriding and finalAttrs referencing #379602

especially

• makeOverridablePythonPackage: simplify implementation and make compatible with <pkg>.overrideAttrs #267296
• buildPythonPackage: preserve the disabled effect after <pkg>.overrideAttrs #376419
• buildPythonPackage: Enable direct attribute overriding via overrideAttrs (the non-staging ones) #376372