What does nixpkgs-review in addition to nixpkgs-update? (In this example it appeared to me they as they did the same thing twice)
Also for the record, from this entry point into the topic, the concept of passthru is neither clear nor discoverable.
So, as a person wanting to write tests in response to the update bot, I’d have to jump over another hurdle and figure that out before. But that’s probably a minor inconvenience.
nixpkgs-review is a tool that builds all the packages in nixpkgs that are affected by a given PR or commit, then it drops you into a shell where you can inspect the build results, and it generates a report about what built and what didn’t.
nixpkgs-update is mainly the software that runs the r-ryantm bot, which collects version update information from external sources (Repology, GitHub releases, PyPI) and uses that to attempt to update packages one at a time. If it succeeds at building the updated package, it runs some checks on it (including nixpkgs-review) and makes a PR. nixpkgs-update can be used as a cli to generate your own package updates and PRs, but it is not very polished for that purpose.
More broadly/philosophically nixpkgs-update is my initiative to keep nixpkgs as up to date as possible, so any work that helps get things more up to date, including improving general PR throughput, is fair game.
This R-RYANTM-HELP.md file should be in the nixpkgs-update repo, where it can be kept up to date. r-ryantm is actually an unprivileged user of the NixOS repo, so it doesn’t make sense for there to be “official” information about it.
I perceive it as a current shortcoming that there is no official documentation of this de-facto standard. I think legitimacy (to make it “official” — under .github) comes out of the value added and the integral part that r-ryantm plays in the ecosystem, if that should be a concern.
I agree on the updating aspect.
All in all, from a end user UX, though, I would want those kind of helps be (officially) discoverable directly from grep NixOs/nixpkgs or — judging by adjacent on-topic content — directly within .github/.
there’s a checkPhase and an installCheckPhase and they correspond to normal make check and make installCheck. The difference is that those phases have to succeed or else it will fail the build.
passthru.tests allows you to run tests which interacts with many packages (e.g. nextcloud + postgres) or allows you to run downstream dependencies (e.g. python3Packages.dash + python3Packages.dash-XXX)
For packages that have a related module, it’s common to create a nixosTests.XXXX which will validate that module still works as well. These can also be added to passthru.tests
python is an awkard ecosystem, so there’s additional toolling around handling common scenarios within python.
It’s not standard for all languages to have such tooling, especially when a language has a standard way to test all packages (python does not, e.g. unittest vs pytest vs nose)
setuptools-check-hook.sh is semi-deprecated because the underlying test setuptools command is deprecated, but kept around for legacy reasons.