chore: Relax dependency constraints

[BeyondEvil]

No description provided.

[sallner]

That is very helpful to have this PR merged and released as the last release broke my CIs because of version constraints, which have worked before. The arguments against upper version constraints also apply for the python version and selenium here. I agree that requests might more difficult as there the version constraints are also very strict.

[BeyondEvil]

That is very helpful to have this PR merged and released as the last release broke my CIs because of version constraints, which have worked before. The arguments against upper version constraints also apply for the python version and selenium here. I agree that requests might more difficult as there the version constraints are also very strict.

THANK YOU for that link!

I spent some time yesterday trying to find best practices around dependency locking, but couldn't really find something comprehensive.

That series of blog posts was exactly what I was looking for.

Found this a little amusing:

If you write a pytest extension, however, then the chances of something breaking are much higher (but not 100%, maybe not even 50%). Quite ironically, the better a package follows SemVer, the smaller the change will trigger a major version, and therefore the less likely a major version will break a particular downstream code.

The "remedy" is obviously to run nightly tests against the main branch of pytest. Which I'm doing for pytest-html and will add here as well.

Question regarding python capping:

If I understand it correctly, if I remove the cap on python, I also have to remove it for the dependencies (like pytest-html), correct?

@sallner

[isaulv]

This follows best practice in terms of a library constraining to what's important.

[Crocmagnon]

I'd love to see this released! 🎉