search

PyFilesystem / pyfilesystem2

Python's Filesystem abstraction layer
https://www.pyfilesystem.org
MIT License
1.99k stars 177 forks source link

Drop Python2.7 support #317

Open willmcgugan opened 5 years ago

willmcgugan commented 5 years ago

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 commented 5 years ago

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

althonos commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@althonos done

djmattyg007 commented 2 years ago

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

djmattyg007 commented 2 years ago

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 commented 2 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?

willmcgugan commented 2 years ago

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 commented 2 years ago

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

lurch commented 2 years ago

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 commented 4 months ago

@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 commented 3 months ago

@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 commented 3 months ago

Last commit two years ago … what do you think?

No harm in trying :)