Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable Python 3.9 in continuous integration #110

Merged
merged 3 commits into from
Nov 26, 2020
Merged

Enable Python 3.9 in continuous integration #110

merged 3 commits into from
Nov 26, 2020

Conversation

jayaddison
Copy link
Contributor

@jayaddison jayaddison commented Nov 26, 2020

  • Remove Python 3.5 continuous integration builds (it's now past end-of-life according to the Python download page)
  • Enable Python 3.9

@@ -7,7 +7,7 @@ jobs:
fail-fast: false
matrix:
os: [ubuntu-latest, macos-latest, windows-latest]
python: [2.7, 3.5, 3.6, 3.7, 3.8, pypy3]
python: [2.7, 3.6, 3.7, 3.8, 3.9, pypy3]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removing 3.5 is a breaking change for frozen-flask, no matter the end of life. The policy is to follow whatever flask itself tests against. I'm inclined to releasing a breaking version, which would drop support for obsolete Python versions (opinions, @tswast?), but then let's do it properly. I quickly checked what versions are supported by flask and it seems they might have dropped even the 2.x line 😮

So my idea would be that we add support for 3.9 and release a minor version. Then we could prepare a version, which drops all the old stuff unsupported by Flask, and only then release a breaking version.

@honzajavorek
Copy link
Contributor

honzajavorek commented Nov 26, 2020

OK I now noticed that frozen-flask is version 0.15, so I'm not sure how closely it follows the semantic versioning scheme. I think a project used by ~2000 ppl and with history going back to 2011 deserves to take off with a "stable" v1.0.0, with which we could drop the old Python version, and from which we could follow with sem ver. Since I'm fairly new here, I'll wait for @tswast's opinions on all this.

@jayaddison
Copy link
Contributor Author

Ah, I just missed your latest comment before pushing changes. Will pause to hear the preferred approach.

@honzajavorek
Copy link
Contributor

honzajavorek commented Nov 26, 2020 via email

@honzajavorek honzajavorek merged commit 3e0d534 into Frozen-Flask:master Nov 26, 2020
@jayaddison jayaddison deleted the python3.9/enable-ci branch November 26, 2020 16:25
@jayaddison
Copy link
Contributor Author

@tswast @honzajavorek Not urgent, but I'm wondering if there's been any further discussion about releasing an updated minor version of frozen-flask with Python 3.9 support?

@tswast
Copy link
Member

tswast commented Jan 12, 2021

I'm wondering if there's been any further discussion about releasing an updated minor version of frozen-flask with Python 3.9 support?

I may have missed it, but were there PRs to fix the library to support Python 3.9? Even without the 3.9 classifier in setup.py, it should be possible to install on 3.9, since there isn't a python_requires field that would prevent it.

@jayaddison
Copy link
Contributor Author

@tswast Yep; my understanding (which may have clouded over a bit since I last looked into this) is that #98 added Py3.9 compatibility, and since then #107 has fixed an incompatibility encountered when using Py2.7.

To be thorough perhaps we should go back and discover when those test failures for Py2.7 began and understand that before a release; the issue relates to handling of multi-byte unicode characters in URLs.

@jayaddison
Copy link
Contributor Author

(taking a look into this now, to try to identify what initially caused the Py2.7 test failures)

@jayaddison
Copy link
Contributor Author

Ok, so the test was introduced a while back in b43242a in May 2011, and while it's neat that it uses Unicode everywhere, I think Python 2.7's urllib.unquote is behaving within the URI spec as-written. Perhaps only IRIs may contain multibyte characters?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants