PyPI classifier for standard library modules/backports?
I started putting together a list of standard library modules that are also available on PyPI for the https://wiki.python.org/moin/Python2orPython3 wiki page. Dariusz Suchojad suggested it might be easier if there was a suitable classifier to mark such modules rather than trying to keep a list on the wiki up to date by hand. Perhaps something like "Progamming Language :: Python :: Standard Library"? Thoughts? Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
-------------------------------------------- On Thu, 2/1/14, Nick Coghlan <ncoghlan@gmail.com> wrote:
Dariusz Suchojad suggested it might be easier if there was a suitable classifier to mark such modules rather than trying to keep a list on the wiki up to date by hand. Perhaps something like "Progamming Language :: Python :: Standard Library"?
I think it makes sense to have "Progamming Language :: Python :: Backport" and "Progamming Language :: Python :: Backport :: Standard Library" While we're on the subject of classifiers, IMO it would also be helpful to be able to identify (the growing number of) projects which are 2 and 3 compatible without the need for 2to3 to be run. So perhaps "Progamming Language :: Python :: Python2and3" or some such. Regards, Vinay Sajip
On Thu, Jan 2, 2014 at 9:37 AM, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
-------------------------------------------- On Thu, 2/1/14, Nick Coghlan <ncoghlan@gmail.com> wrote:
Dariusz Suchojad suggested it might be easier if there was a suitable classifier to mark such modules rather than trying to keep a list on the wiki up to date by hand. Perhaps something like "Progamming Language :: Python :: Standard Library"?
I think it makes sense to have
"Progamming Language :: Python :: Backport"
and
"Progamming Language :: Python :: Backport :: Standard Library"
While we're on the subject of classifiers, IMO it would also be helpful to be able to identify (the growing number of) projects which are 2 and 3 compatible without the need for 2to3 to be run. So perhaps
"Progamming Language :: Python :: Python2and3"
or some such.
How is that any better than specifying the Python 2 classifier and the Python 3 one? One should specify every individual version of Python that a project is supposed to be compatible with anyway so I don't see the benefit of knowing through a classifier if 2to3 is needed or not.
-------------------------------------------- On Thu, 2/1/14, Brett Cannon <brett@python.org> wrote:
"Progamming Language :: Python :: Python2and3" or some such.
How is that any better than specifying the Python 2 classifier and the Python 3 one? One should specify every individual version of Python that a project is supposed to be compatible with anyway so I don't see the benefit of knowing through a classifier if 2to3 is needed or not.
At the moment, if a classifier indicates that a distribution is both 2 and 3 compatible, there is no declarative way to indicate whether or not 2to3 is to be run - only via a setuptools.setup argument. I'm not hung up on whether a classifier is used, but I think there should be *some* declarative mechanism. A classifier has the advantage that it could be applied to a specific release in the index without changing its code. Regards, Vinay Sajip
On Thu, Jan 2, 2014 at 11:12 AM, Vinay Sajip <vinay_sajip@yahoo.co.uk>wrote:
-------------------------------------------- On Thu, 2/1/14, Brett Cannon <brett@python.org> wrote:
"Progamming Language :: Python :: Python2and3" or some such.
How is that any better than specifying the Python 2 classifier and the Python 3 one? One should specify every individual version of Python that a project is supposed to be compatible with anyway so I don't see the benefit of knowing through a classifier if 2to3 is needed or not.
At the moment, if a classifier indicates that a distribution is both 2 and 3 compatible, there is no declarative way to indicate whether or not 2to3 is to be run - only via a setuptools.setup argument. I'm not hung up on whether a classifier is used, but I think there should be *some* declarative mechanism. A classifier has the advantage that it could be applied to a specific release in the index without changing its code.
I guess my question then is "why do you care?" If 2to3 is run at install time then it's a cost, but it's one-time and if you really care you can always create your own wheel of the translated code or something. I guess I just don't view the overhead of some packages using 2to3 to be enough to warrant a classifier that only some people will use (it's hard enough to try and get people to use proper classifiers for what version of Python they support as it is).
I guess my question then is "why do you care?" If 2to3 is run at install time then it's a cost, but it's one-time and if you really care you can always create your own wheel of the translated code or something.
Because I've written a packaging tool that doesn't use setup.py but instead uses a fully declarative format for building and installing packages, and I don't want that tool to run what can be a time-consuming step every time it installs certain packages, when that step isn't necessary. It's not a common use case, I grant you :-) Regards, Vinay Sajip
On 3 Jan 2014 08:20, "Vinay Sajip" <vinay_sajip@yahoo.co.uk> wrote:
I guess my question then is "why do you care?" If 2to3 is run at install time then it's a cost, but it's one-time and if you really care you can always create your own wheel of the translated code or something.
Because I've written a packaging tool that doesn't use setup.py but
instead uses a fully declarative format for building and installing packages, and I don't want that tool to run what can be a time-consuming step every time it installs certain packages, when that step isn't necessary. It's not a common use case, I grant you :-) Also getting into the metabuild system design. The idea of classifiers potentially having programmatic effects is one that hadn't previously occurred to me - I've always just viewed them as advisories for human readers. However, it would only apply when installing from an sdist (not a wheel), so I don't believe the extra complexity is worth it at this point - for the moment, setup.py remains the only "defined" build system. However, we should definitely make sure that it is covered in the development of the metabuild system. Cheers, Nick.
Regards,
Vinay Sajip
participants (3)
-
Brett Cannon -
Nick Coghlan -
Vinay Sajip