Drop Python2.7 support

[willmcgugan]

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.

[zopyx]

May Python 2.7 rest forever.
No need for further Python 2.7 compatibility.

[althonos]

Fine 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.

[bennr01]

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.

pyfilesystem2 currently has the major version 2, which would mean that the next major version would be 3. As most of you probably know, a python package ending with 3 usually indicates py3-only support, which would coincide with the change.

This would also allow py2-projects to specify fs < 3.0.0 as a dependency.

On the other hand, bumping the major version of a package in a repo called pyfilesystem2 may lead to confusion, so I am not sure whether this change should really be done in accordance with semantic versioning.

[dargueta]

a 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 2 ending 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.

[willmcgugan]

@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.

[odgalvin]

@althonos I could go through and remove the Python 2 compatibility bits if you'd like a PR? Maybe after your next point release. It would tidy up the code a lot.

[althonos]

@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.

[atollk]

Is this an ongoing discussion? Having worked quite a bit on different parts of the fs code 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.

[althonos]

@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.

[willmcgugan]

@althonos done

[djmattyg007]

Are there any updates on this? It would be nice to lose the dependency on six 🙏

[djmattyg007]

It'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.

[lurch]

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?

[willmcgugan]

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.

[djmattyg007]

That probably depends on whether or not you consider the compatibility code to be part of the public interface of the package.

[lurch]

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".

[edgarrmondragon]

@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?

[mcepl]

@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?

[edgarrmondragon]

Last commit two years ago … what do you think?

No harm in trying :)