maintainership & project lead

[mcmtroffaes]

Follow up from #66.

The main activity for pathlib2 is to backport any updates from cpython into this repository, typically a few times a year, with the main development of pathlib happening in upstream cpython. As stated, in the long term, I really would like to stand down as lead maintainer. I'm happy to keep helping along in the background e.g. reviewing PRs and submitting trivial patches if need be.

Is someone interested (e.g. someone who uses pathlib2 in their work) to take on the lead responsibility for this package?

[hendrikmakait]

After a gentle nudge from @graingert, I'd volunteer to take over lead responsibilities for pathlib2. I'm pretty sure I could use a helping hand in the beginning as well as a short summary of where things stand.

[mcmtroffaes]

Thanks so much @hendrikmakait! I'm thrilled to learn that you are willing to step up, and I deeply appreciate it. I'll be happy to help out with reviewing and any other small things you might need, definitely in the year to come.

The last Python 2.x version was released, so that means only Python 3.x needs to be supported for pathlib2 going forward. The code was resynced to cpython as part of #75 so the diff should be much smaller than it used to be, making it easier to track cpython. This said, there hasn't been a merge from upstream for quite some time (basically, since #75): in the past I've typically waited until folks posted issues about non-supported features they needed from cpython, but that hasn't happened in a while. It has been surprisingly quiet in terms of issues/PRs.

Do you have any specific questions?

[hendrikmakait]

Thanks @mcmtroffaes for the summary! From what I understand, the next step would be to do another sync with CPython and get a release of pathlib2 out that only supports Python3 and see what happens after that. Is that correct?

in the past I've typically waited until folks posted issues about non-supported features they needed from cpython, but that hasn't happened in a while. It has been surprisingly quiet in terms of issues/PRs.

I can imagine two reasons for this:

• People using this only wanted a Python2-compatible backport of pathlib and have stopped supporting Python2 since, removing a need for pathlib2. We should see that in the download statistics after releasing a Python3-only version of pathlib2.
• People are genuinely interested in a backport of new pathlib features but have been discouraged by the lack of activity on the repository or simply stumbled across the EOL-warning that has been removed in February. This will be trickier since those people need to realize that pathlib2 will have been updated to include the latest features added since 3.9 with the next release.

[mcmtroffaes]

Thanks @mcmtroffaes for the summary! From what I understand, the next step would be to do another sync with CPython and get a release of pathlib2 out that only supports Python3 and see what happens after that. Is that correct?

That's correct, indeed. The master branch is in a pretty good shape and the port is done, however it's probably good to get it first some real world beta testing since the code has changed a lot: to move to Python 3, the code at the time was copied fresh from cpython, and then any test failures on older Python were fixed one by one. This has resulted in much cleaner code than the old Python 2 codebase.

• People using this only wanted a Python2-compatible backport of pathlib and have stopped supporting Python2 since, removing a need for pathlib2. We should see that in the download statistics after releasing a Python3-only version of pathlib2.
• People are genuinely interested in a backport of new pathlib features but have been discouraged by the lack of activity on the repository or simply stumbled across the EOL-warning that has been removed in February. This will be trickier since those people need to realize that pathlib2 will have been updated to include the latest features added since 3.9 with the next release.

Yup, I think that sums it up. I expect the package to eventually go the way of the dodo. As pathlib in cpython is now quite mature, and fewer features are being added, the need for pathlib2 is already much less than it used to be.

[barneygale]

Hey - I'm the poor sap maintaining pathlib in CPython nowadays. I'm planning to introduce a new pathlib.PathBase class in Python 3.13, which users can subclass to implement virtual filesystems (paths in zip files, on S3, etc). It would help adoption a great deal if a backport package is available for older Pythons (<=3.12). It sounds like our goals might be aligned here? If so, I'd like to offer my services, either as maintainer/lead of pathlib2 or as author of a bunch of PRs :]

[mcmtroffaes]

Hey there! Many thanks for reaching out. Though I don't have much say here as I'm only the former poor sap maintaining pathlib2, I support either of your suggestions.

[barneygale]

I'll start updating this package once the following changes land in upstream pathlib:

• GH-72904: Add glob.translate() function python/cpython#106703
• GH-110109: Move tests for pathlib.Path.walk() into main test classes. python/cpython#110655
• GH-110109: Add pathlib._PurePathBase python/cpython#110670

[barneygale]

Hey, I'm afraid I'm no longer planning to update this package. I made an attempt, but backporting recent os.path.realpath() behaviour for Path.resolve() was pretty difficult. Instead I've backported just the internal ABCs as pathlib-abc. I'm sorry to anyone this disappoints.

[mcmtroffaes]

Ok, thanks for letting us know!