mf2py
mf2py copied to clipboard
microformats
Deprecate Python 2 support?
Are we ready to go Python 3 only? In 2020, Python 2.7 is going end-of-life. A bunch of popular Python projects including Django and Twisted have already announced Python 3 exclusivity. If we went to Python 3 support, we could add type annotations and so on.
Just as a quick survey: is there anyone using mf2py on Python 2? Do you have a plan to move to Python 3 soon?
Yes, appengine classic is still 2.7 only, so both unmung and @snarfed's appengine projects use it
On Wed, 21 Feb 2018, 14:03 Tom Morris, [email protected] wrote:
Are we ready to go Python 3 only? In 2020, Python 2.7 is going end-of-life. A bunch of popular Python projects including Django and Twisted have already announced Python 3 exclusivity. If we went to Python 3 support, we could add type annotations and so on.
Just as a quick survey: is there anyone using mf2py on Python 2? Do you have a plan to move to Python 3 soon?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tommorris/mf2py/issues/87, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGCwNC13IUCoPXXEwtLa9g9Ehcqt0Hlks5tXCJCgaJpZM4SNr7q .
quite true. apologies!
I've made a lot of progress porting granary (and oauth-dropins) to at least python 3 compatible, using http://python-future.org , but i can't go python 3 only until app engine standard ships their support.
That's a shame, but a pretty clear blocker. Apparently AppEngine is tied to Java 7 too. Google, always on the cutting edge, I guess. 😉
Can I nudge this again nearly four years later? Python 2.x is EOL, as is Python 3 before 3.6. Google App Engine supports Python 3 and they no longer recommend 2.7 at all. It'd be really nice to finally end 2.x support.
The other way we can support 2.x is basically to say "all future builds will be 3-only, if you're running 2.x, you need to pin to 1.1.2 and we won't fix anything for 2.x anymore".
Yes! Sounds great. My stuff all migrated to Python 3 a few years ago, so I'm ready. And yes, following semver and cutting a new major version is the right way to drop Python 2 support. Anyone who still needs it would pin to <2.0.
Bridgy was pretty much the reason we wanted to keep Python 2 support for as long as we did, if it doesn't need it anymore I'd agree -> Python2 support can be deprecated.
Pin to 1.1.2 sounds good to me, as GAE Python3 deprecates a huge pile of useful tooling, so unmung will be running 2.x until I replace it entirely.
On Thu, Jan 13, 2022 at 11:00 PM Sven @.***> wrote:
Bridgy was pretty much the reason we wanted to keep Python 2 support for as long as we did, if it doesn't need it anymore I'd agree -> Python2 support can be deprecated.
— Reply to this email directly, view it on GitHub https://github.com/microformats/mf2py/issues/87#issuecomment-1012594540, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAYFQFCZSOKNK7P2P7ONZDUV5KQPANCNFSM4ERWX3VA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID: @.***>
Should we press a 1.1.3 or 1.2 release before moving to 2.0?
https://packaging.python.org/en/latest/guides/dropping-older-python-versions/ describes using python_requires in setup.py to properly signal the deprecation -- eg. add python_requires='>=2.7' to a final 1.x release and then change to python_requires='>=3.7' in the following 2.x release.
https://github.com/microformats/mf2py/compare/main...angelogladding:mf2py:final-py2 is a start
https://stackoverflow.com/a/56135899/6841359 describes bumping semver minor for a mark of deprecation--so jump to v1.2? Also, do we need to add a deprecation message to the README? 2.7 has been EOL since 2020-01-01 https://devguide.python.org/versions/
I have been pairing with @angelogladding on this. The test suite is no longer running properly because the ubuntu-latest environment to which the test suite is pinned no longer supports the Python versions stipulated in our Actions manifest. For us to get the test suite back up and running, we will need to deprecate support for v2.7 and v3.6, for which there is no supported environment in GitHub Actions. See https://github.com/actions/setup-python/issues/544 for more information on this point.
I propose that we make a final release with the repository in its current state and tag it as the final version for publication on v2.7 and v3.6, both versions of Python that have reached their End of Life.
Yes the deprecation of EOL python versions should come first. Modern systems won't support <3.7.
I believe the correct path forward is to push a patch release (to follow existing versioning) with the setup.py python_requires>=2.7 metadata added: https://github.com/microformats/mf2py/pull/187/commits/b07418f70ec14aa8afe410453bd12f8296e45c62
Then we can actually remove python2 support https://github.com/microformats/mf2py/pull/179/commits/78c8f7ff87225df764ff6c16addf2a65d41a982a and continue with the other "modernizations".
When we move to poetry and pyproject.toml replaces setup.py we'll designate python = ">=3.7" and poetry will automatically generate a setup.py with python_requires>=3.7 on publish for legacy python2 environments.
Pip will know not to update open-ended mf2py>=1.1.2 requirements.txt files in py2/<=py3.6 envs to 1.2.
I believe we should move away from patch-based feature releases toward minor releases. Thus this first release after the deprecation of py2 should be a minor release. It should not be a major release as there's technically no change to the public API--no one's code anywhere needs to change.