@GrahamcOfBorg eval

Ofborg's new maintainer ping algorithm would have requested a review from:

• @nixy for pkgs.python27Packages.astor, pkgs.python37Packages.astor, pkgs.python27Packages.astor, pkgs.python37Packages.astor, pkgs.python27Packages.astor, pkgs.python27Packages.astor, pkgs.python37Packages.astor, pkgs.python37Packages.astor
• @knedlsepp for pkgs.python37Packages.pandas, pkgs.python27Packages.pandas, pkgs.python27Packages.pandas, pkgs.python37Packages.pandas, pkgs.python37Packages.pandas, pkgs.python37Packages.pandas, pkgs.python27Packages.pandas, pkgs.python27Packages.pandas
• @FRidh for pkgs.python37Packages.datashape, pkgs.python37Packages.datashape, pkgs.python37Packages.pandas, pkgs.python27Packages.traitlets, pkgs.python37Packages.traitlets, pkgs.python27Packages.pandas, pkgs.python37Packages.traitlets, pkgs.python37Packages.traitlets, pkgs.python27Packages.traitlets, pkgs.python27Packages.pandas, pkgs.python27Packages.datashape, pkgs.python27Packages.traitlets, pkgs.python37Packages.pandas, pkgs.python37Packages.datashape, pkgs.python37Packages.pandas, pkgs.python37Packages.datashape, pkgs.python27Packages.traitlets, pkgs.python37Packages.pandas, pkgs.python27Packages.datashape, pkgs.python27Packages.pandas, pkgs.python27Packages.datashape, pkgs.python37Packages.traitlets, pkgs.python27Packages.pandas, pkgs.python27Packages.datashape
• @zimbatm for pkgs.python37Packages.pip-tools, pkgs.python27Packages.pip-tools, pkgs.python37Packages.pip-tools, pkgs.python27Packages.pip-tools, pkgs.python37Packages.pip-tools, pkgs.python27Packages.pip-tools, pkgs.python37Packages.pip-tools, pkgs.python27Packages.pip-tools
• @7c6f434c for pkgs.python37Packages.pandas, pkgs.python27Packages.pandas, pkgs.python27Packages.pandas, pkgs.python37Packages.pandas, pkgs.python37Packages.pandas, pkgs.python37Packages.pandas, pkgs.python27Packages.pandas, pkgs.python27Packages.pandas
• @catern for pkgs.python37Packages.trio, pkgs.python37Packages.trio, pkgs.python37Packages.trio, pkgs.python37Packages.trio

does this seem reasonable? please discuss on NixOS/ofborg#293

runTests returns a string, and can therefore unfortunately not be overridden. If, instead, buildPython* would accept a parameter, say, checkConfig, whose value corresponds to an attribute set, then it would be possible to write:

buildPythonPackage {
  ...

  checkConfig = {
    runner = pytest;
    variables.FOO = "bar";
    disabledTests = [
      "test_this"
    ];
  };
}

where the runner gets to decide how to invoke the test.
I don't want to over-engineer it (mainly just have a solution for disabledTests), but considering we have different test runners it may be convenient. At the same time, nose is being used fewer and fewer.

Just two points here:

1. Was there a particular reason not to use a build-support hook? This would allow overrideAttrs to work as expected when disabledTests becomes an attribute of the derivation.
2. Can we get documentation for this function in the manual?

Was there a particular reason not to use a build-support hook? This would allow overrideAttrs to work as expected when disabledTests becomes an attribute of the derivation.

Regarding hooks, there are two options:

1. hook exported by the derivation, pytest, itself.
2. a separate hook, say pytestRunner.

I don't think 1) is a good solution because pytest may be just some dependency. Using a specific attribute for it would solve that (mypkg.testRunner = pytest;). At that point one might as well go for 2).
Instead of adding new top-level attributes (such as say disabledTests) I prefer to put everything test-related in its own namespace. Are attribute sets exported as associative arrays?

Can we get documentation for this function in the manual?

Of course, once we settle on the solution.

Are there any updates on this pull request, please?

Will continue with hook approach.