# Howto deal with Pallets Projects dependencies **URL:** \ **Category:** Organisation\ **Created:** [March 30, 2022, 10:31pm UTC](https://discuss.tryton.org/t/howto-deal-with-pallets-projects-dependencies/5148 "2022-03-30T22:31:12Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\ **Post date:** [March 30, 2022, 10:31pm UTC](https://discuss.tryton.org/t/howto-deal-with-pallets-projects-dependencies/5148/1 "2022-03-30T22:31:13Z")
It is now clear that the Pallets Projects is no more following semver. They break API compatibility in feature release, ex: - [Changes — Werkzeug Documentation (3.1.x)](https://werkzeug.palletsprojects.com/en/2.1.x/changes/#version-2-1-0) where they removed deprecate code which were public API. - [markupsafe/CHANGES.rst at main · pallets/markupsafe · GitHub](https://github.com/pallets/markupsafe/blob/main/CHANGES.rst#version-210) where they removed again public API We also have [Add support for werkzeug 2.0 (#10086) · Issues · Tryton / Tryton · GitLab](https://bugs.tryton.org/issue10086) which raises multiple times concern about the maintenance of older branch. Indeed the project has stated multiple times that once a new “branch” is released, all previous are deprecated and no more maintained. And now [Werkzeug new release breaks the test (#11353) · Issues · Tryton / Tryton · GitLab](https://bugs.tryton.org/issue11353). With such behavior, I think we could not rely on the release number to have any meaning and we should consider that it is like a pre-stable project. So I think we should try our best to make all supported Tryton series compatible with the latest version of the pallets projects releases but also with the largest possible older release (by using fallback, API test etc.). If we agree on this rule, we should backport all the fixes. ---
**Author:** ![yangoon](https://discuss-cdn.tryton.org/letter_avatar_proxy/v4/letter/y/67e7ee/32.png) [@yangoon](https://discuss.tryton.org/u/yangoon)\ **Post date:** [March 31, 2022, 6:41am UTC](https://discuss.tryton.org/t/howto-deal-with-pallets-projects-dependencies/5148/2 "2022-03-31T06:41:25Z")
Here another statement with regard to the subject [Importing jinja2 fails with ImportError from MarkupSafe #1596](https://github.com/pallets/jinja/issues/1596). I fully agree. ---
**Author:** ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)\ **Post date:** [March 31, 2022, 7:10am UTC](https://discuss.tryton.org/t/howto-deal-with-pallets-projects-dependencies/5148/3 "2022-03-31T07:10:09Z")
I think we do not have any other option as it is clear they do not follow semver and they do not want to support older series. > [@ced](#): > > So I think we should try our best to make all supported Tryton series compatible with the latest version of the pallets projects releases but also with the largest possible older release (by using fallback, API test etc.). Agree but as it is clear that they only support latest released serie we should make our latest version compatible only with newer releases and remove all the code compatible to older releases. Does it make sense for you? ---
**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\ **Post date:** [March 31, 2022, 7:27am UTC](https://discuss.tryton.org/t/howto-deal-with-pallets-projects-dependencies/5148/4 "2022-03-31T07:27:46Z")
> [@pokoli](#): > > Agree but as it is clear that they only support latest released serie we should make our latest version compatible only with newer releases and remove all the code compatible to older releases. Does it make sense for you? No it is not because they are bad at maintaining older releases that we should be bad. For me we must define a minimal supported version. For werkzeug I would say 0.11 which was released 2 years before our 5.0. which seems reasonable guess about what people would have on system when they upgraded to 5.0. We may update to 0.15 for 6.0 series. Now I’m wondering if we should not have a dedicated test which force to install the lower supported version to ensure we are still compatible with it. Also I would be in favor of remove dependencies to werkzeug for modules. Instead of importing from werkzeug we should provide a cleaned API for the tools we need in modules like: exceptions, response and redirect. This will help us to maintain support for various version of werkzeug in a single place. ---
**Author:** ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)\ **Post date:** [March 31, 2022, 7:34am UTC](https://discuss.tryton.org/t/howto-deal-with-pallets-projects-dependencies/5148/5 "2022-03-31T07:34:26Z")
> [@ced](#): > > For werkzeug I would say 0.11 which was released 2 years before our 5.0. which seems reasonable guess about what people would have on system when they upgraded to 5.0. We may update to 0.15 for 6.0 series. Does it make sense to use the version included on debian stable on the time of the LTS version is released? That will be a good reference for stable points. And what about 6.2 and 6.4 series? As far as 1.0 and 2.0 is should we use that version or just keep the old dependencies? > [@ced](#): > > Now I’m wondering if we should not have a dedicated test which force to install the lower supported version to ensure we are still compatible with it. Makes sense for me, but probably just for trytond and not for all modules. > [@ced](#): > > Also I would be in favor of remove dependencies to werkzeug for modules. Instead of importing from werkzeug we should provide a cleaned API for the tools we need in modules like: exceptions, response and redirect. It also make sense. But do you want to backport such API or just use it for newer series? I will consider backporting it to ease the maintenance of older series. ---
**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\ **Post date:** [March 31, 2022, 7:58am UTC](https://discuss.tryton.org/t/howto-deal-with-pallets-projects-dependencies/5148/6 "2022-03-31T07:58:58Z")
> [@pokoli](#): > > Does it make sense to use the version included on debian stable on the time of the LTS version is released? That will be a good reference for stable points. Well it is an indication but we should not tie ourselves to rules that we do not control. > [@pokoli](#): > > And what about 6.2 and 6.4 series? As far as 1.0 and 2.0 is should we use that version or just keep the old dependencies? For me supporting the most version possible is the best. So it will be a trade-off between code complexity and maintenance. But at some point it will be easier for maintenance that between LTS we do not change the minimal version supported. > [@pokoli](#): > > But do you want to backport such API or just use it for newer series? I think we can go with only new series because back porting will create a dependency between bugfix release of module and bugfix release of trytond. Also for now what we used in those module has not been a problem. ---
**Author:** ![nicoe](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/nicoe/32/2880_2.png) [@nicoe](https://discuss.tryton.org/u/nicoe)\ **Post date:** [March 31, 2022, 9:02am UTC](https://discuss.tryton.org/t/howto-deal-with-pallets-projects-dependencies/5148/7 "2022-03-31T09:02:15Z")
> [@ced](#): > > Also I would be in favor of remove dependencies to werkzeug for modules. Instead of importing from werkzeug we should provide a cleaned API for the tools we need in modules like: exceptions, response and redirect. This will help us to maintain support for various version of werkzeug in a single place. And why not dropping Werkzeug, in favor of something more reliable? What we need is: - a `Request` object - a `Response` object - some routing system - a minimal server for development - **a project that follow semver** As there is no shortage of WSGI framework in python from the minimalist [bottle](https://bottlepy.org/docs/0.12/index.html) to [Pyramid](https://trypyramid.com/) which is a complete web framework, there’s probably one that is well suited for our needs. ---
**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\ **Post date:** [March 31, 2022, 9:12am UTC](https://discuss.tryton.org/t/howto-deal-with-pallets-projects-dependencies/5148/8 "2022-03-31T09:12:13Z")
We do not need a web framework but a WSGI library which allows use to expose a WSGI app to any WSGI server. So for me the only alternative I know is [`wsgiref`](https://docs.python.org/3/library/wsgiref.html) but we will need to create some tools to simplify the management (like werkzeug did). ---
**Author:** ![nicoe](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/nicoe/32/2880_2.png) [@nicoe](https://discuss.tryton.org/u/nicoe)\ **Post date:** [March 31, 2022, 9:19am UTC](https://discuss.tryton.org/t/howto-deal-with-pallets-projects-dependencies/5148/9 "2022-03-31T09:19:26Z")
> [@ced](#): > > We do not need a web framework but a WSGI library which allows use to expose a WSGI app to any WSGI server. I know but we don’t have to use all the bell and whistle from the project we chose just like we don’t use the debugger of Werkzeug. > [@ced](#): > > So for me the only alternative I know is [`wsgiref`](https://docs.python.org/3/library/wsgiref.html) but we will need to create some tools to simplify the management (like werkzeug did). I guess that’s what bottle is doing also since they only depend on the standard lib. So we might as well reuse what they’re doing and contribute back if necessary. ---
**Author:** ![nicoe](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/nicoe/32/2880_2.png) [@nicoe](https://discuss.tryton.org/u/nicoe)\ **Post date:** [March 31, 2022, 9:40am UTC](https://discuss.tryton.org/t/howto-deal-with-pallets-projects-dependencies/5148/10 "2022-03-31T09:40:22Z")
> [@nicoe](#): > > So we might as well reuse what they’re doing and contribute back if necessary. Pyramid is using [https://webob.org/](https://webob.org/) Which also doesn’t depend on anything except the standard library. ---
**Author:** ![edbo](https://discuss-cdn.tryton.org/letter_avatar_proxy/v4/letter/e/f14d63/32.png) [@edbo](https://discuss.tryton.org/u/edbo)\ **Post date:** [March 31, 2022, 9:57am UTC](https://discuss.tryton.org/t/howto-deal-with-pallets-projects-dependencies/5148/11 "2022-03-31T09:57:57Z")
I think that the test-system must be updated to filter out the deprecation warnings. Functionality is not removed all of a sudden, but there are deprecation warnings before. So you can update your code or pin the to the current version. So instead of moving away, maybe a change in the test-system will do the trick. You can even think of automatically creating an issue when a deprecation warning pops up (be careful with that it may flood the issue tracker). ---
**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\ **Post date:** [March 31, 2022, 10:14am UTC](https://discuss.tryton.org/t/howto-deal-with-pallets-projects-dependencies/5148/12 "2022-03-31T10:14:57Z")
> [@nicoe](#): > > Pyramid is using [https://webob.org/](https://webob.org/) > > Which also doesn’t depend on anything except the standard library. And what will be the cost of such migration? > [@edbo](#): > > I think that the test-system must be updated to filter out the deprecation warnings. Functionality is not removed all of a sudden, but there are deprecation warnings before. How do you make that tests are failing because **our code** is using a deprecated feature of a library and not when it is a external dependency? > [@edbo](#): > > So you can update your code or pin the to the current version. Pinning dependency is not a solution because Tryton is a public project so we can not force everyone to use the exact version we choose. But also pinning prevent security update. For example Pallets Project has this argument to justify to not follow the semver, they say that user must pin their dependencies. But they do not even follow their own recommendation because their own projects (which depend on each other) are not pinned. And so some version of Flask does not work with some version of werkzeug but there is no information in the requirements about which versions work with which one. ---
**Author:** ![nicoe](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/nicoe/32/2880_2.png) [@nicoe](https://discuss.tryton.org/u/nicoe)\ **Post date:** [March 31, 2022, 11:09am UTC](https://discuss.tryton.org/t/howto-deal-with-pallets-projects-dependencies/5148/13 "2022-03-31T11:09:43Z")
> [@ced](#): > > And what will be the cost of such migration? I don’t know but it’s less than re-implementing everything from scratch and maybe comparable to providing a compatibility layer to werkzeug. But the risk is higher since it’s a library that we haven’t work with until now. On the other hand we wouldn’t have the burden of supporting their changes every time (provided that the behaviour of the webob devs is not the same as the one from the pallet project). ---
**Author:** ![edbo](https://discuss-cdn.tryton.org/letter_avatar_proxy/v4/letter/e/f14d63/32.png) [@edbo](https://discuss.tryton.org/u/edbo)\ **Post date:** [March 31, 2022, 12:08pm UTC](https://discuss.tryton.org/t/howto-deal-with-pallets-projects-dependencies/5148/14 "2022-03-31T12:08:03Z")
> [@ced](#): > > How do you make that tests are failing because **our code** is using a deprecated feature of a library and not when it is a external dependency? I didn’t say that the test should be failing because of a deprecation. When you look for example at [https://drone.tryton.org/tryton/trytond/1054/10](https://drone.tryton.org/tryton/trytond/1054/10) you will find deprecation warnings in the log. You can filter these out and make them available somewhere else. Because when the tests are ‘green’ you generally don’t look at the log and are missing this deprecation warnings. And this goes beyond the Pallets Project. > [@ced](#): > > But also pinning prevent security update. That’s an issue. > [@ced](#): > > So I think we should try our best to make all supported Tryton series compatible with the latest version of the pallets projects releases but also with the largest possible older release (by using fallback, API test etc.). I think this is the best solution. ---
**Author:** ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)\ **Post date:** [April 1, 2022, 8:06am UTC](https://discuss.tryton.org/t/howto-deal-with-pallets-projects-dependencies/5148/15 "2022-04-01T08:06:11Z")
> [@nicoe](#): > > > [@ced](#): > > > > And what will be the cost of such migration? > > I don’t know but it’s less than re-implementing everything from scratch and maybe comparable to providing a compatibility layer to werkzeug. I see one problem here: We have versions already released with werkzeug so untils those versions are active maintained we will need to support werkzeug. As 6.0 series is LTS version we need to keep compatibility with werkzeug for 4 years. The change to new library will make harder to support LTS versions. ---
**Author:** ![nicoe](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/nicoe/32/2880_2.png) [@nicoe](https://discuss.tryton.org/u/nicoe)\ **Post date:** [April 1, 2022, 10:49am UTC](https://discuss.tryton.org/t/howto-deal-with-pallets-projects-dependencies/5148/16 "2022-04-01T10:49:35Z")
Indeed switching would make supporting previous versions really cumbersome. ---
**Author:** ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)\ **Post date:** [April 14, 2022, 7:43am UTC](https://discuss.tryton.org/t/howto-deal-with-pallets-projects-dependencies/5148/17 "2022-04-14T07:43:41Z")
As it seems to have a good consensus on this. I will backport to all supported series, the fixes: - [Add support for werkzeug 2.0 (#10086) · Issues · Tryton / Tryton · GitLab](https://bugs.tryton.org/issue10086) - [Werkzeug new release breaks the test (#11353) · Issues · Tryton / Tryton · GitLab](https://bugs.tryton.org/issue11353) And I have created [Remove direct dependency to werkzeug in modules (#11407) · Issues · Tryton / Tryton · GitLab](https://bugs.tryton.org/issue11407) for future series.