On Thu, Apr 15, 2021 at 8:50 AM Christopher Barker <python...@gmail.com> wrote:
> On Thu, Apr 15, 2021 at 2:40 AM Victor Stinner <vstin...@python.org> > wrote: > >> Paul Bryan: >> > Seems like this is something that should make its way into stdlib? >> >> In the last 10 years, the trend is more to remove anything related to >> packaging *outside* the stdlib :-) > > > Well, maybe all of us don't think that's a good idea ;-) > As an active participant in the PyPA side of the packaging ecosystem and one of the maintainers of 'packaging', I am definitely NOT in favour of moving any of 'packaging' into the stdlib, nor breaking it up. We are taking distutils out of the stdlib for a reason. Backsliding on plans that have been in place for years is not something I would want to see happen as the motivations have not changed. > > But anyway, I would say removing anything *related* to packaging outside > the stdlib is a bad idea -- requiring an external tool to build a package > is OK, but requireing an external use packages, not so much. > You can totally use a package already as things exist today and will in the future; you're just wanting a specific way to interpret a package's metadata which I don't view as the same thing. > > Presumably that's why importlib.metadata exists in the stdlib. > It's there because of how tightly it binds to the import system; same goes for importlib.resources. > > Version is arguably useful from the package user side. As I believe Victor > mentioned, there are two uses for version information: display to the user > -- for which version strings are fine, or programmatic comparison -- for > which something like the Version object is very helpful. Do we only need to > use version information programmatically when we are creating (or > installing) packages? I don't think so -- I know I have code that (poorly) > does version checking programmatically. > No one said that's the *only* use-case, but just because there's more than that does not mean we should move any packaging code into the stdlib to support a zero-install use-case. A key point I want to make here is the version metadata is in every project's .dist-info/METADATA file. That's what importlib.metadata knows how to read and hence why people have been suggesting to use it. The version information is fundamental to the wheel format and in fact you can't have a wheel without it. So asking every Python project to set a __version__ isn't going to change accessibility of version numbers when it comes to installed projects.
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/V5WJW2HRRTSUN34ZHTVV2HVSBS4MMBSX/ Code of Conduct: http://python.org/psf/codeofconduct/
