Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Motivation for this change
So i touched again a topic that is missing a clear policy? I hoped this is just a simple update.
I think it's not an option to not update packages. We should automate the process as much as possible and make updating simple. And hopefully automate updating completely in the future. That is my vision.
In this case i would try to fix all breaking packages by updating them too.
I tried to build and test the depending packages with nix-review but the tool seems broken.
How would you go further with pytest? Close this PR and wait for an important update? Wait for some time like 3 months?
Could you seriously stop the complaining? Thinking one can "just" automatically update everything is extremely shortsighted. It would require setting up rules and thresholds for all packages along with extensive CI that is just not going to happen. This is a mass-rebuild, and with mass-rebuilds we need to be careful. This is a package that is known to cause breakage upon updates. Therefore, it warrants extra care. How that is done is in the end up to the package maintainers.
Not updating is an option, and is in fact often the sane one as well. Continuously updating is expensive because of the high amount of work it takes, and it is thus doubtful whether there is any net gain in doing so.
Given the amount of breakage that pytest tends to produce, I tend to only consider updating it when it is required for something depending on the update.
This is far from perfect, but pytest updates are a pain otherwise.
So my personal guideline is: if someone needs an update, lets go for it, if it is an update just for an update, it might not be worth the effort (pytest is a build-time dependency, no impact on production systems, I would not have the same approach for software that actually run on production).