doc: emphasize trade-off between versionCheckHook and testers.testVersion #344321
Conversation
ofborg
bot
added
10.rebuild-darwin: 0
10.rebuild-linux: 1-10
10.rebuild-linux: 1
labels
|
Related case: when i expanded |
| @@ -1,6 +1,6 @@ | |||
| # versionCheckHook {#versioncheckhook} | |||
|
|
|||
| This hook adds a `versionCheckPhase` to the [`preInstallCheckHooks`](#ssec-installCheck-phase) that runs the main program of the derivation with a `--help` or `--version` argument, and checks that the `${version}` string is found in that output. You use it like this: | |||
| This hook adds a `versionCheckPhase` to the [`preInstallCheckHooks`](#ssec-installCheck-phase) that runs the main program of the derivation with a `--help` or `--version` argument, and checks that the `${version}` string is found in that output. If the test fails then the whole build will fail. You use it like this: | |||
| @@ -169,7 +169,7 @@ The build will fail if `shellcheck` finds any issues. | |||
|
|
|||
| Checks that the output from running a command contains the specified version string in it as a whole word. | |||
|
|
|||
| NOTE: In most cases, [`versionCheckHook`](#versioncheckhook) should be preferred, but this function is provided and documented here anyway. The motivation for adding either tests would be: | |||
| NOTE: If you want a version check failure to trigger a build failure, then [`versionCheckHook`](#versioncheckhook) is preferred. The motivation for adding either tests would be: | |||
There was a problem hiding this comment.
That's a good start for the sentence, but I don't think that the average contributor knows whether they would like to trigger a build failure or not. Perhaps here, or in the NOTE at the end of the diff we can lay out arguments why would someone want the failure to block and when not?
Personally I don't see a reason why it shouldn't block.
There was a problem hiding this comment.
Some upstreams do not have a bump script but instead do releases by hand. This risks tagging versions where the version provided in e.g. package.json is incorrect.
There was a problem hiding this comment.
Some upstreams do not have a bump script but instead do releases by hand. This risks tagging versions where the version provided in e.g.
package.jsonis incorrect.
Isn't that a good sign that the package.json should be patched? and that upstream would want to know about that? And perhaps it also means that users reporting upsteram bugs with that incorrect version would confuse them?
There was a problem hiding this comment.
Indeed, but we don't have any large-scale automated reporting on r-ryantm bump failures yet (this may be subject to change), meaning version check failures could make updates stop coming in
EDIT: that argument applies to any sanity-checks not put in passthru.tests
There was a problem hiding this comment.
Here are some arguments for and against. I'm not sure whether including it is beneficial, but I can do it if you prefer so. Please help me flesh out the arguments in that case :)
Cases for versionCheckHook
* Stricter, blocks build on version check failure
* Requires the entrypoint to be hermetic enough to print its version
Cases for testers.testVersion
* Does not block build on version check failure
* The output of potentially long running builds are thus not discarded
* Bot updates such as r-ryantm will happen more often, in turn triggering maintainer pings and review.
* Works with non-hermetic entrypoints, dependant on certain environment variables
There was a problem hiding this comment.
EDIT: that argument applies to any sanity-checks not put in passthru.tests
Sanity checks other then versionCheckHook not in passthru.tests? What do you mean?
- Requires the entrypoint to be hermetic enough to print its version
But that's also a case to not use any version test :). Also, people may not understand what is an entrypoint, or what do you mean by "hermetic".
- Bot updates such as r-ryantm will happen more often, in turn triggering maintainer pings and review.
Isn't this correct only in the rare case where upstream released the new version manually and forgot to update the VERSION file or package.json version or whatever? Also, I wonder whether r-ryantm will notice that and not even open a PR, as you may have noticed that it says every time: "found ${version} with grep in /nix/store/....`.
- Works with non-hermetic entrypoints, dependant on certain environment variables
So if by "hermetic" you mean that an executable may need an environment variable like $HOME to even do the simple version print, that is not explained well with this phrasing. An example of such a case was observed here: https://github.com/NixOS/nixpkgs/pull/339197/files#diff-dc99f6cd821b428eaa2723c4ef39f37283f34ab8c1c430c9b6a8963e64b5a24cR88-R89, and indeed it is worth mentioning, but I'm not sure yet where. Also, in the future I might add support for inheriting environment variables when trying to get version in versionCheckHook, and then this won't be an issue.
- Does not block build on version check failure
- The output of potentially long running builds are thus not discarded
I would agree upon something like this:
If you have a long and heavy to build package that you are not yet sure how to test it's version print or if it has any, then you may want to postpone the addition of
versionCheckHookto a more mature state of the package and it's expression in Nixpkgs.
Description of changes
I'm not a fan of the recent push to migrate to
versionCheckHook. This is a decision better left to each package maintainer, rather than drive-by fixups or some notion of prescribed "best practice".Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.