WeasyPrint 63.0 blocks upgrade of Pyphen to version 0.17

[gmseb]

Hello WeasyPrint team,

thanks for WeasyPrint! 🙏

It came to my attention today that line…

WeasyPrint/pyproject.toml

Line 20 in ca74c8e

'Pyphen >=0.9.1,<0.16',

…currently blocks upgrading Pyphen to 0.17 in the environment. It would be nice if that could be unblocked and this combination be supported. Thank you!

Best, Sebastian

[liZe]

We have a problem here, see #2294.

Before version 63, upper versions were not fixed, leading to problems like #2207. Now that they are fixed, we got two issues opened in less than a week.

We could enable dependabot to automatically get PRs for new versions, but we don’t want to release new WeasyPrint versions each time a dependency is updated. So that’s probably useless.

Many other libraries (Flask, Scikit-Learn, Pillow…) don’t define upper versions, maybe it was a bad idea to add them in WeasyPrint.

@gmseb @paulocoutinhox @nijel @violuke Feedback is welcome, don’t hesitate to share your needs and explain what would be best for you.

[gmseb]

@liZe thanks for your reply!

With my Gentoo packager hat on, I have a clear vote for "no upper boundaries please" as downstream will need to patch them out a la https://github.com/gentoo/gentoo/blob/master/app-containers/docker-compose/files/docker-compose-1.29.0-setup-py.patch whenever the environment outlives the package (and hence the upper boundaries prove having been overly strict in practice).

[liZe]

With my Gentoo packager hat on, I have a clear vote for "no upper boundaries please"

Thanks a lot for your feedback (with my Gentoo user hat on)!

[paulocoutinhox]

Hi @liZe,

In my opinion is important keep dependencies updated and a new version compatible need be released.

You can adopt semver (https://semver.org/), and update the last number, example: 63.0.1.

It won't make any practical difference for you whether you release it or not, but for me as a user of the library it will. In these cases, I have to point directly to the master branch repository to bypass this.

Thanks.

[nijel]

I think Pillow API is pretty stable and unlikely to introduce a breaking change, so removing the upper bound is certainly an option. The other option is to release a point release fast as soon as new version is tested (what should be automated via renovate or dependabot). We use that for Weblate.

[nijel]

Another thing to consider is that Pillow as track of fixing security issues in major releases (AFAIR it happened in 9.0.0 and 10.0.0), so users might be pushed to upgrade this particular dependency fast.

[gmseb]

Let me add that for known incompatible combinations, use of != gets the good parts but not the trouble that < brings.

[gmseb]

For pydyf the solutions is probably to add support for pydyf 0.11.0 and then use pydyf>=0.11.0 if necessary. Just thinking aloud, I haven't done proper research in here on the very topic yet.

[liZe]

Thanks a lot for you feedback. ❤

For pydyf the solutions is probably to add support for pydyf 0.11.0 and then use pydyf>=0.11.0 if necessary.

That was another problem: 0.11.0 broke older versions of WeasyPrint.

Another thing to consider is that Pillow as track of fixing security issues in major releases (AFAIR it happened in 9.0.0 and 10.0.0), so users might be pushed to upgrade this particular dependency fast.

Yes, that’s another good reason to remove upper boundaries.

In my opinion is important keep dependencies updated and a new version compatible need be released.

You can adopt semver (https://semver.org/), and update the last number, example: 63.0.1.

It won't make any practical difference for you whether you release it or not, but for me as a user of the library it will. In these cases, I have to point directly to the master branch repository to bypass this.

We don’t want to release patch versions, and even if we did it may not be the best idea to change dependencies it patch versions.

But you’re right, it’s important to keep dependencies updated, more important than having older unsupported WeasyPrint versions broken when their dependencies are updated.

Let’s remove these upper boundaries, that wasn’t a good idea to add them. If we ever break older WeasyPrint versions, we can handle the bug reports as we did for pydyf 0.11.0.

[paulocoutinhox]

Thanks. Im only wait for the new version to update my project to that.