For me, it is working with this version.
The deprecation warning talk about breaking in version 1.0 not in version 0.16. As far as I see there is still backward compatibility.
Cédric Krieradded 1 deleted label and removed 1 deleted label
Indeed our CI is broken due to this issue and I tested on local to update werkzeug from 0.14 to 0.16 and after that I cannot run trytond for import errors.
Sorry, my test on local was failing by an obsolete version of module timesheet that was using werkzeug.exceptions.Response
This is the traceback of drone server:
from trytond.wsgi import app
File "/drone/src/.tox/py36-sqlite/lib/python3.6/site-packages/trytond/wsgi.py", line 12, in <module>
from werkzeug.contrib.fixers import ProxyFix
ModuleNotFoundError: No module named 'werkzeug.contrib'
Reviewing the log, I see the system is installling Werkzeug==1.0.0rc1.
> Reviewing the log, I see the system is installling Werkzeug==1.0.0rc1.
FYI:
- if I create a fresh virtualenv and install trytond 5.0 it installs werkzeug 0.16.1.
- if I run tox for a foundation module it installs werkzeug 0.16.1.
- if I run tox for an own module it installs werkzeug 1.0.0rc
Indeed werkzeug pre-released 1.0.0rc1 and as tox install with --pre option, it picks up the pre-release.
I have mix feeling about how to solve this. We could backport #8235 (closed) but that send the message that we will support new major versions of dependencies for old series. Or we could limit the dependency to werkzeug<1.0 (this may be a problem on Docker build as we use the Debian package for werkzeug without version limitation).
Cédric Krieradded 1 deleted label and removed 1 deleted label
> Indeed werkzeug pre-released 1.0.0rc1 and as tox install with --pre option, it picks up the pre-release.
> I have mix feeling about how to solve this. We could backport #8235 (closed) but that send the message that we will support new major versions of dependencies for old series. Or we could limit the dependency to werkzeug<1.0 (this may be a problem on Docker build as we use the Debian package for werkzeug without version limitation).
I see your doubts. IMHO I would choose the second option and limit version in docker build as well (if it is possible).
El 6/2/20 a les 11:28, Cédric Krier ha escrit:
> we could limit the dependency to werkzeug<1.0 (this may be a problem on Docker build as we use the Debian package for werkzeug without version limitation).
I will prefer this solution as I do no think we should support new major version of dependencies (otherwise it can be a nightmare)
For the docker image we use the debian package for werkzeug [1] which contains 0.14 version [2], so I do not see any issue on it.
I jump on that thread as we just have the problem in Tumbleweed, as werkzeug 1.0 arrived there.
> I will prefer this solution as I do no think we should support new major version of dependencies (otherwise it can be a nightmare)
Considering the fact that 5.0 should be around 4 more years in maintenance, we will have to deal with new releases. Otherwise Tryton will not run on a more or less up-to-date software stack.
>For the docker image we use the debian package for werkzeug [1] which contains 0.14 version [2], so I do not see any issue on it.
0.14 is already more than 2 years old...and not everyone runs Tryton in a container
We already fixed in changeset7e1081cd7a76 it be requiring werkzeug <1.0 for 5.0 series.
As Tumbleweed is a rolling release I think you should upgrade your tryton packages to latest release (5.4) which works well with new werkzeug releases.
Am Mittwoch, 26. Februar 2020, 16:07:33 CET schrieb Sergi Almacellas Abellana:
> Sergi Almacellas Abellana <sergi@koolpi.com> added the comment:
>
> We already fixed in changeset7e1081cd7a76 it be requiring werkzeug <1.0 for
> 5.0 series.
This is not a fix, this is a workaround
> As Tumbleweed is a rolling release I think you should upgrade your tryton
> packages to latest release (5.4) which works well with new werkzeug
> releases.
5.4 is not really an option, as it has a too short support cycle (you may
remember that I voted against the 'new' support model)