tox-dev / platformdirs

A small Python module for determining appropriate platform-specific dirs, e.g. a "user data dir".
https://platformdirs.readthedocs.io
MIT License
568 stars 49 forks source link

Adding to stdlib/pathlib? #265

Open matterhorn103 opened 7 months ago

matterhorn103 commented 7 months ago

Hi, I love this module and use it all the time. Many thanks for everyone's work!

Given platformdirs provides such key functionality with a fairly small footprint, is it insane to think that maybe it could be added to the Python standard library?

Given that pathlib already has Path.home(), maybe it could just be added to pathlib? Accessed with from pathlib import PlatformDirs? And then function identically to the way it does now?

gaborbernat commented 7 months ago

This is a question to the core developers, however as far as I know, there's been an active effort to have less in the standard library as it's easier to update . 🤔 You can open an issue for the core developers at https://github.com/python/cpython/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc

gaborbernat commented 7 months ago

Please link to this issue if you open an issue there, thanks!

matterhorn103 commented 7 months ago

Fair enough. I started a discussion thread on the Python ideas board. :)

matterhorn103 commented 7 months ago

The reception was cautiously positive I'd say. The utility was definitely recognised.

Actually they didn't feel size of the stdlib is an issue – only whether users benefit more from the functionality being in the stdlib or available as a package. Their main concerns being:

  1. the frequency of new releases that platformdirs receives – but this seems mostly to do with your release policy of making new releases for pretty much every commit, correct?
  2. feature updates would be only possible at most once a year, and fixes would be slow to release and permeate through the Python ecosystem.

As a current maintainer, your opinion is the most important one here. Do you think users would benefit significantly from having it as a separate package with the possibility of rapid updates? And how often are breaking changes likely, in your view?

To me as an outsider, the pace of change of operating systems seems slow enough that stability feels like not really a concern.

gaborbernat commented 7 months ago

From my point of view there's benefit in both. It could even operate the same way importlib.resources does today where it is still released on its own but periodically mirrored into the standard library.

gaborbernat commented 7 months ago

And yes, I think the project is stable enough nowadays and we don't plan any major changes.

ofek commented 7 months ago

Maybe going into the standard library we could fix that macOS issue? I forget which one but it would be a major change.

gaborbernat commented 7 months ago

Yeah we could have another round of deep review before we cut over, I would only do that though if you get verbal acord that the project would be accepted into the standard library, probably in a mirrored fashion as is importlib.resources is.

hugovk commented 7 months ago

There are no verbal agreements, the steps for acceptance would be to find a core dev to sponsor, write up a PEP, submit it for community discussion (and update the PEP if needed), then submit it to the steering council for acceptance. PEP 1 has the details.

A good reference is PEP 680 ("tomllib: Support for Parsing TOML in the Standard Library"), that added (the read-only parts of) tomli to the stdlib.

A mirrored fashion sounds sensible, it would make it easier to contribute bug fixes and new features. The common parts of tomli and tomlib remain very similar too. (I recently checked and they were almost identical.)

matterhorn103 commented 7 months ago

Yes, it would maybe be a good opportunity to tidy up some things or change some things if you guys wanted. In a way, it's a chance for any last really big breaking changes. Namespaces, for example, if there were any lingering regrets from the past however many years.

I also wondered whether, for a PEP proposal, you might see it as desirable to slim down the package by only returning the paths as Path objects, whereas currently everything is doubled for both Paths and strings, right? Just an idea though.

matterhorn103 commented 7 months ago

By the way, since no one really asked for my opinion and I was the one who came here with irritating ideas keen to make more work for everyone – I'm very happy to contribute in any way I can :)

gaborbernat commented 7 months ago

By the way, since no one really asked for my opinion and I was the one who came here with irritating ideas keen to make more work for everyone – I'm very happy to contribute in any way I can :)

It would be great if you could write up the PEP proposal, I would be happy to review it and push it through. We can be co authors in that sense if you're fine with that 👋

matterhorn103 commented 7 months ago

I can have a stab at it, sure. As long as you don't mind a multitude of questions about the implementation :)