DEV: Ensure testing against the latest versions

[stefan6419846]

At the moment, CI uses fixed package versions. Despite being under active development, this hides possible incompatibilities with newer package versions, as recently seen for pytest>=8. On the other hand, this ensures that CI failures are most likely not related to external changes.

In my opinion, it would make sense to add some additional CI job which always uses the latest external package versions and thus ensures that pypdf keeps working with the latest updates. We might use https://github.com/py-pdf/pypdf/blob/main/requirements/ci.in directly for this, although we should ensure that we only have lower bounds in this case (fpdf2 is currently pinned there to an old version).

[MartinThoma]

I think it's important to distinguish packages used only for CI/testing and packages used as a dependency (like the cryptography packages):

• User-facing dependencies should support a very wide range so that pypdf is easy to use with other libraries
• CI/testing dependencies should be reliable. That means we need to have a pinned version that works.

If we can, we should also support more than that version in CI. But in my opinion the priority is clearly on the reliability, less on the range of support.

I also wonder how many CI-minutes we are allowed to execute. I don't want to execute too much there to keep the Github ecosystem for free (yes, I realize pypdf by it's own does not matter - but thousands of repositories being careful with spending too much CI minutes will add up)

[MartinThoma]

ensures that pypdf keeps working with the latest updates

I'd rather have a make maint command. I've added this in many of my projects to regularly update dependencies.

We could also extend depdendabot for the update :-)

[stefan6419846]

I am aware that there are lots of opinions about this. Personally, most of my projects always use the latest dependency versions in CI while aiming at providing backwards compatibility as much as possible and setting lower limits if known/required.

Manual updates tend to be annoying and easily forgotten, thus automation makes more sense in my opinion - whether through dependabot or some other approach. IMHO the easiest approach would be to have a dedicated job which just uses the latest dependencies on the latest supported Python release and is allowed to fail, but quickly indicates if something is going to be broken - fixing the failures will invoke the regular pinned jobs anyway and thus ensure that we stay backwards-compatible.

[MasterOdin]

I agree with @MartinThoma in that for a library, should treat runtime dependencies and dev dependencies separately, where the former should be tested at the lowest + highest supported versions on CI, while the dev dependencies should be fixed to provide a working experience out of the box. Like, it doesn't really matter on using an old version of pytest so long as it has there's not bug fixes/features you want/need in the latest version, so long as yeah, sort of keep on top of it (such as through dependabot).

[stefan6419846]

To add some additional context: In #2427, it has been reported that the latest pytest version (released shortly before) leads to issues with pypdf as we were catching warnings which never actually occurred in our code at these positions. As we are not testing with pytest==8 at the moment, each PR could break this again, thus I opened this issue to further evaluate how we want to continue with these cases.

This does not mean that pypdf should always require the latest versions of all external dependencies - keeping a suitable range of supported versions is always appreciated. (I have seen projects in the past which have explicit pins of their dependencies and a new release for each updated dependency, which is neither required nor allows for easy integration into larger projects with tons of dependencies. I clearly do not want pypdf to become such a "bad" example.)