Repository navigation
Drop Python2.7 support #317
Description
Activity
May Python 2.7 rest forever.
No need for further Python 2.7 compatibility.Reacted by Will McGugan, Jan Willems, Frank Villaro-Dixon, wovano and Diego ArguetaFine by me, I'm not putting any particular effort for Python 2.7 support right now so I don't care about dropping support.
IMO you should make a last stable release so that all libraries can pin that version more easily in case some devs stuck in the past need to pin anything.Reacted by Will McGugan, Diego Argueta and bennr01- pinned this issue
on Aug 3, 2019 Small suggestion: dropping py2 support is technically a backwards incompatible api change. When following semantic versioning, this should be indicated by a major version bump.
pyfilesystem2currently has the major version2, which would mean that the next major version would be3. As most of you probably know, a python package ending with3usually indicates py3-only support, which would coincide with the change.This would also allow py2-projects to specify
fs < 3.0.0as a dependency.On the other hand, bumping the major version of a package in a repo called
pyfilesystem2may lead to confusion, so I am not sure whether this change should really be done in accordance with semantic versioning.Reacted by Jan Willemsa python package ending with 3 usually indicates py3-only support
Package name or package version? I agree with the name.
On the other hand, bumping the major version of a package in a repo called pyfilesystem2 may lead to confusion
I do agree that the
2ending has put us in an unfortunate position, but we're going to have to bump the major version at some point. Otherwise we'll be violating the principle of semantic versioning.@bennr01 I concur 3.0.0 is the way to go when we drop Python2 support.
The name on Pypy is still
fs. I hope the repos name containing a 2 doesn't confuse too many people. I can always put a note in the readme if it does.Reacted by bennr01 and Jan Willems@odgalvin : as Will mentioned, we should make a new repository for that, probably forking this one into PyFilesystem/pyfilesystem3. Plus, it would be great to take advantage of this breaking change to actually address a lot of the breaking issues.
EDIT: I will have more time next week-end to start planning this, and to triage the current PyFilesystem2 issues.
Is this an ongoing discussion? Having worked quite a bit on different parts of the
fscode base recently, I agree with @althonos that a chance to perform some breaking changes should be used to clean up as well. I feel like I could chime in with some ideas and would be willing to take up some of the resulting tasks, should we agree on the direction that PyFs3 wants to take.@atollk : it's still something i'd like to spend more time on when I can, but not much progress has been done so far, except I started to triage some issues that might be breaking changes.
@willmcgugan : could you add @atollk to the PyFilesystem organization? It would make it easier to discuss and coordinate there.
Reacted by Andreas Tollkötter@althonos done
Reacted by Andreas TollkötterReacted by Martin LarraldeAre there any updates on this? It would be nice to lose the dependency on
six🙏Reacted by Diego Argueta, Thomas Coenen, Lucas Resch and Edgar Ramírez MondragónIt's also a real issue for making contributions in general, because suddenly I have to care about a language I've literally never used. Working with python2 in any capacity has been a painful experience for a long time, especially since it went EOL over two years ago.
Having just read through this again I agree that this is a backwards-incompatible change and thus (according to the semver rules) warrants a major-version-bump (which coincidentally brings us to 3.0.0), but I don't think that it warrants a new package-name or repo?
I concur that it should warrant a bump to 3, but not a new repo or package.
We could do that at any point really. i.e. we don't need to wait to strip out the 2.7 stuff to declare we don't care about Python 2 compatibility any longer. The work of removing the various 2.7 compatibility fudges could be incremental.
Reacted by Andrew Scheller, Martin Larralde and Edgar Ramírez MondragónThat probably depends on whether or not you consider the compatibility code to be part of the public interface of the package.
whether or not you consider the compatibility code to be part of the public interface
That's why we're doing a major-version-bump. After pyfilesystem 3.0.0 the backwards-compatibility code (for Python2.7) may be removed at any point, and is no longer part of the "supported interface".
@althonos If I submitted PRs to get package metadata and Python version support up-to-date (drop < 3.8, test with 3.11+) do you think they'd be reviewed and merged?
Last commit two years ago … what do you think?
No harm in trying :)
Python2.7 will be unsupported in a few months. We should drop Python2.7 before then.
I'm keen to do this as Python2.7 support has long been a headache. If anyone has a good reason to keep Py2.7 support, please make your case in this issue.