Flask/Werkzeug 2.1 compatibility

[Glandos]

Since Werkzeug 2.1, some deprecated symbols were removed.

• Some symbols were still used by Flask-sqlalchemy 2.4. Their use were removed in 2.5, not mentionned in changelog, only in pallets-eco/flask-sqlalchemy@331a040
• Flask-WTF 1.0.1 added compatibility
• Require Flask 2.1
• Python 3.6 support is removed.

Do we really want to drop Python 3.6 now?

[Glandos]

OK, this was tougher that I imagined.

Werkzeug is not pinned in our setup.cfg. It seems that the minimal requirements don't pin it also, so 2.1 was brought into the "minimal" setup and broke tests.

The choice is here:

• Upgrade to Flask/Werkzeug 2.1 and drop Python 3.6
• Pin Werkzeug to < 2.1

I'm usually in favor of going forward and drop old versions. Raise your voice here to oppose!

[Glandos]

@zorun I tried to update vermin to set -t=3.7, but something is weird for me here. It keeps saying that the code is valid for Python 3.6, and since I asked for 3.7, the return code is 1.

But I want to ensure that it is at least 3.7.

[zorun]

Hmm, it's logical that vermin still says 3.6, because our code needs at least 3.6 (because of f-strings).

In fact, I simply configured vermin wrongly. After playing with it, the right target would be -t=3.7- (with the minus at the end). It says that requiring python 3.7 or any lower version (3.6 in our case) is fine.

[zorun]

About dropping support for python 3.6: as usual, I don't like it! Ubuntu 18.04 comes with python 3.6, and is still supported for many years to come.

What I propose: let's pin the older version of werkzeug for now, and if in the future we need to break compatibility for another reason (which means increasing our major version number), we can drop python 3.6 at the same time.

[almet]

Hey, I'd vote in favor of dropping support for older python versions. While I agree with your reasoning @zorun when it comes to desktop applications, for a web application I think we can move faster without it being a problem for our end users.

If people want to still use ubuntu 18.04, having an older IHM version is okay I believe. It's of course open to discussion :-)

[almet]

I see another option : we could make two branches in our code, and act differently depending on the version of python, and then remove this conditional once we want to remove support for python 3.6.

That would work for me as well. I haven't checked what actual code was doing this on our side though.

[zorun]

If people want to still use ubuntu 18.04, having an older IHM version is okay I believe. It's of course open to discussion :-)

... until somebody discovers that the older IHM version has a security hole :p

I see another option : we could make two branches in our code, and act differently depending on the version of python, and then remove this conditional once we want to remove support for python 3.6.

From what I understood, it's Werkzeug that dropped support for python 3.6, so we can't make two branches in our own code.

To rephrase my position:

1. since we use semantic versioning, dropping python 3.6 means that we have to increase the major version number (6.0.0 instead of 5.x.y). This could be discussed because I'm not sure semantic versioning actually covers this case, but with my sysadmin hat on, I'm very strongly in favour of a major version bump for this case.
2. increasing the major version number just for dropping python 3.6 is not really worth it, we should group this with other breaking changes.

[almet]

I'll let you decide on this: every option seems acceptable to me and I don't have à strong opinion. If you need somebody else to make a choice let me know but otherwise, I'll be happy any way !

[Glandos]

OK, so my current opinion on this is that we don't really need Werkzeug/Flask 2.1 for now. So let's stack this for the 6.0 release, and in the meantime, we'll pin these dependencies with <2.1

[Glandos]

So for now, this won't be merged