Nixpkgs: Package tests

[NeQuissimus]

Unless I got lost in the package tree, I don't see any tests other than those in nixos/tests, which are effectively for the NixOS modules.

I want to start adding package tests, primarily for all those package I regularly update/maintain.

a) Where should I put those
b) How would I bootstrap them? (I want them to be run as part of the channel updates, not unlike the nixos/tests files)
c) Do we have concerns with Hydra build times if/when people were to start adding lots of tests?

/cc @vcunat @domenkozar @edolstra @shlevy @aszlig @fpletz @globin @joachifm @copumpkin @grahamc (just pinging people who usually have good opinions on these things, anybody is welcome to provide feedback)

[fpletz]

I know that @Profpatsch has already put a lot of thought into package tests and has some code ready. Not sure where, though. :)

[Profpatsch]

Yes! It’s nearly finished!
@NeQuissimus, if you want we can chat (Profpatsch on freenode, [email protected] on Jabber/XMPP) and I can show you what I got so far.

[NeQuissimus]

@Profpatsch Very good, I will wait for the PR. Ping me when you have something reviewable :)
A little while ago I added a test for ammonite, not realizing that tests need to be explicitly bootstrapped. So I believe my test does not run at all right now. I just want a simple solution that lets us test packages, since we do have a good amount of breakage on a regular basis...

[Profpatsch]

For people who already want to write package tests, I’ve written a short overview on how to do it until the implementation gets merged:

https://github.com/NixOS/nixpkgs/pull/27641#issuecomment-319235606

[NeQuissimus]

@Profpatsch PING :D Any status updates? :)

[Profpatsch]

Not yet. I will be working on it some more over the next month.

[dtzWill]

Ping? :innocent:

[kamilchm]

@Profpatsch any progress? :)

[timokau]

36842 essentially implements this right?

[Profpatsch]

@timokau Parts of it. I should really merge my code.

Wouldn’t comment on this thread too much, since it mentions so many people.

[davidak]

@Profpatsch, @7c6f434c, @timokau what is the status of this effort?

Was the whole idea abandoned after https://github.com/NixOS/nixpkgs/pull/36842 was rejected?

I'm still waiting for a good way to annotate packages with simple tests. Do you agree that checkPhase inside the derivation is currently the best way to do it? Would it be useful if package maintainers add it to their packages? Especially in the context of https://github.com/ryantm/nixpkgs-update/issues/13 and possibly duplicated effort. @ryantm

[jtojnar]

@davidak IMHO checkPhase is not a good place since it cannot be run independently of the package build. Tweaking the test would mean rebuilding the whole package, and so would disabling flaky test.

Me and @worldofpeace are adding new nixos tests to passthru.tests (example). r-ryantm runs derivations listed in that attribute (https://github.com/ryantm/nixpkgs-update/pull/118) and ofborg might do that as well (https://github.com/NixOS/ofborg/pull/410).

I think using runCommand in there might also work nicely.

[JohnAZoidberg]

I think using runCommand in there might also work nicely.

Yes! For simple programs an entire VM test is overkill and a derivation running a few commands is enough. See for example: https://github.com/NixOS/nixpkgs/pull/72855/files#diff-7ff02ed41d58b0e67d73301d85d22a40R3

[7c6f434c]

@davidak I join the recommendation to use passthru.tests over checkPhase for tests we add in Nixpkgs without relying on the upstream tests. I think we also have some support for upstream's installed-tests.

@JohnAZoidberg the worst part is that even for LibreOffice NixOS VM tests are a bit of an overkill (VM setup takes longer than the test itself, starting LibreOffice and clicking on stuff and checking menus actually appear via OCR), but there we need to refactor the necessary functionality, such as launching display server and D-Bus.

[timokau]

The downside of passthru.tests is that test failures won't fail the build and tests are not run automatically. Linking nixos tests has also a discoverability problem.

[JohnAZoidberg]

@timokau that's just a tooling problem. We have to teach our tools to do this. Hydra, r-ryantm, ofBorg and maybe nix build --with-tests.

I think it would even be useful to extract the checkPhase to its own derivation, so that changing the test doesn't cause a rebuild for the program's derivation.

[timokau]

I don't think tooling is a nice solution for this. As long as running tests is optional, many people won't run them when making changes. Also many people will install broken packages from hydra without knowing they are broken. I like @Profpatsch's approach much better (inverting the dependencies so that the packages depend on their tests, IIRC).

I'm not saying that passthru.tests is bad, just that its not optimal in my view.

[7c6f434c]

Unavoidable tests, though, create a pressure to reduce them (to make installation faster) — so realistically we could switch from opt-in to opt-out, but mandatory will lead to a different conflict of interest.

[timokau]

Yeah, the reverse-dependency approach would essentially be opt-out. Each package could provide an untested attribute that skips the tests. I think opt-in would lead to a lot of failing tests that are just accepted.

[7c6f434c]

I guess we end up having an untested set like we have pkgsi686Linux, but yeah, not having it as a default might be a good idea.

I do not think that including the tests in the main build itself leads to a good balance of incentives, so I guess putting them into passthru.tests for now is an OK idea.

(I guess in the long run we could teach mkDerivation that sequentialisation trick by @Profpatsch and give it a list of functions from untested outputs to installed tests)

[stale[bot]]

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the
   related code and @ mention them in a comment.
2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
   irc.freenode.net.