PEP 345 update + RFC on "Requires-External" and "Requires-Python"
Hello I've update PEP 345 with a first draft about the markers, http://python.org/dev/peps/pep-0345/#environment-markers PEP 390 is being reworked accordingly, but I guess we can have a new round of comments on PEP 345 and PEP 386, as they can be accepted and added in Python independently from the other PEPs. There's also a "Requires-External" field that was added in the first update of 345, that we need to discuss. The idea of this field is to be able to define a non-Python dependency in the metadata. It's based on a list stored and managed at PyPI. Values could be things like "libxslt", "libpng", etc.. Last, "Requires-Python" is introduced to define the version of Python. I am not sure this is required anymore since Martin has added a Trove classifier for this. But in the meantime, this is stronger than a "simple" classifier I think. Any comments ? Regards Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
On Nov 14, 2009, at 4:09 PM, Tarek Ziadé wrote:
Last, "Requires-Python" is introduced to define the version of Python. I am not sure this is required anymore since Martin has added a Trove classifier for this. But in the meantime, this is stronger than a "simple" classifier I think.
+1 for Requires-Python. This is a simpler field to understand than scanning through a list of Trove classifiers. Both for filling out the metadata, and for displaying on PyPI, since it would (arguably) be easier to read: Requires Python: >2.4, <2.7 Than: Categories: Programming Language :: Python :: 2.4 Programming Language :: Python :: 2.5 Programming Language :: Python :: 2.6 Especially for packages with a large number of categories. Although the easiest to read would be: Requires Python: 2.4, 2.5, 2.6 At least I find it easier to map "2.4, 2.5, 2.6" to "requires Python 2.4, or Python 2.5 or Python 2.6" than translating from the >< ranges into specific Python releases supported (which the Trove categories already naturally suports). Perhaps just making a note in the PEP or Distutils docs recommending this format "2.4, 2.5, 2.6", or at least making it the primary example of using field, and recommending other uses for special-case packages. Erm, actually, re-reading the Requires Python section in PEP 345 I guess the conditional operator is required, so it would actually be: Requires Python: ==2.4, ==2.5, ==2.6 Is that right? Perhaps in the absence of a conditional operator, then == should be the default, since I think it'd be easy to misunderstand this field upon casual usage. But then it should also make explicit in the PEP that ==2.5 is taken to mean only 2.5.0 or the entire sereis of releases in the 2.5 line. But then arguably there aren't even enough special cases to justify the extra syntax to support things such as ">= 2.5.2"? I would imagine that almost all packages, when they release just test against the latest releases of whatever versions of Python that project supports? Also for the minor releases the other Python implementations, they aren't lock step with the CPython minor releases are they? e.g. Jython has a 2.5.0 release and 2.5.1 release, but that 2.5.1 isn't the same as CPython 2.5.1 (I could be wrong about this, haven't looked in depth). Finally, it actually only makes sense to tag specific distributions for which versions of Python they support. So for example the Grok project: Grok 1.0: Requires Python: 2.4, 2.5 Grok 1.1: Requires Python: 2.5, 2.6 Which means that they PyPI would say "Grok supports Python 2.5 and Python 2.6" after 1.1 is released. Which might not be true if there was still maintenance releases happening in the 1.0.x line. So they what should the project specify here? So maybe I'm -0 on this field, since it does seems ambigous or the information is specific to the distributions and not the overall project.
On Sun, Nov 15, 2009 at 1:18 AM, Kevin Teague <kevin@bud.ca> wrote:
Also for the minor releases the other Python implementations, they aren't lock step with the CPython minor releases are they? e.g. Jython has a 2.5.0 release and 2.5.1 release, but that 2.5.1 isn't the same as CPython 2.5.1 (I could be wrong about this, haven't looked in depth). For Jython at least, this is correct. The 2.5 part tells you which CPython we are targeting, but the x in 2.5.x is entirely Jython specific.
-Frank
On Sun, Nov 15, 2009 at 7:18 AM, Kevin Teague <kevin@bud.ca> wrote: [..]
Erm, actually, re-reading the Requires Python section in PEP 345 I guess the conditional operator is required, so it would actually be:
Requires Python: ==2.4, ==2.5, ==2.6
Is that right? Perhaps in the absence of a conditional operator, then == should be the default, since I think it'd be easy to misunderstand this field upon casual usage.
That's a multi-line field, so at the end, Distutils will return a list with the value of all lines. For "==" I guess we can specify in the field that it's the default operator, I'll add that.
But then it should also make explicit in the PEP that ==2.5 is taken to mean only 2.5.0 or the entire sereis of releases in the 2.5 line.
I think that ==2.5 should target the entire 2.5.x series.
But then arguably there aren't even enough special cases to justify the extra syntax to support things such as ">= 2.5.2"? I would imagine that almost all packages, when they release just test against the latest releases of whatever versions of Python that project supports? Also for the minor releases the other Python implementations, they aren't lock step with the CPython minor releases are they? e.g. Jython has a 2.5.0 release and 2.5.1 release, but that 2.5.1 isn't the same as CPython 2.5.1 (I could be wrong about this, haven't looked in depth).
Answering to Frank here too: We can suppose that a program that works with Jython, can safely use jython versions in Requires-Python, unless it's possible for a given program to run on CPython *and* Jython and that it's impossible to use a common MAJOR.MINOR version ?
Finally, it actually only makes sense to tag specific distributions for which versions of Python they support. So for example the Grok project:
Grok 1.0: Requires Python: 2.4, 2.5
Grok 1.1: Requires Python: 2.5, 2.6
Which means that they PyPI would say "Grok supports Python 2.5 and Python 2.6" after 1.1 is released. Which might not be true if there was still maintenance releases happening in the 1.0.x line. So they what should the project specify here?
So maybe I'm -0 on this field, since it does seems ambigous or the information is specific to the distributions and not the overall project.
I am not sure why you say there's an ambiguity, because PyPI doesn't give the metadata of a project, but of a distribution. (and as a matter of fact, some PyPI UIs will automatically use the latest distribution of the project, but that's just a default behavior) So the "Grok supports Python 2.5 and Python 2.6" sentence doesn't exists anywhere. It's "Grok 1.1 supports Python 2.5 and Python 2.6" or "Grok LATEST_VERSION supports Python 2.5 and Python 2.6" Tarek
So maybe I'm -0 on this field, since it does seems ambigous or the information is specific to the distributions and not the overall project.
I am not sure why you say there's an ambiguity, because PyPI doesn't give the metadata of a project, but of a distribution. (and as a matter of fact, some PyPI UIs will automatically use the latest distribution of the project, but that's just a default behavior)
Erm, yeah ... ignore that last bit I wrote, it's just flat out wrong. I think I said it because I quit drinking coffee and it's made my head foggy :P (although this idea probably came from PyPI's default behaviour, is there a way to list all distributions for a project on PyPI? I guess that's a question for catalog-sig)
On Tue, Nov 17, 2009 at 5:20 PM, Kevin Teague <kevin@bud.ca> wrote: [...]
(although this idea probably came from PyPI's default behaviour, is there a way to list all distributions for a project on PyPI? I guess that's a question for catalog-sig)
The XML-RPC API offers this through "package_releases", see: http://wiki.python.org/moin/PyPiXmlRpc
On Tue, 17 Nov 2009 08:20:23 -0800, Kevin Teague <kevin@bud.ca> wrote:
(although this idea probably came from PyPI's default behaviour, is there a way to list all distributions for a project on PyPI?
Yeah of course, see: http://wiki.python.org/moin/PyPiXmlRpc David
On Tue, Nov 17, 2009 at 8:51 AM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
Answering to Frank here too:
We can suppose that a program that works with Jython, can safely use jython versions in Requires-Python,
unless it's possible for a given program to run on CPython *and* Jython and that it's impossible to use a common MAJOR.MINOR version ? I think it will be very rare to find a program that works on both but only on different MAJOR.MINOR versions. It is *possible* - for example, we have an ast.py in Jython 2.5 even though CPython does not get this until 2.6 (ast.py as a replacement for pyc bytecode manipulation was just too compelling for us to ignore).
-Frank
On Tue, Nov 17, 2009 at 7:59 PM, Frank Wierzbicki <fwierzbicki@gmail.com> wrote:
On Tue, Nov 17, 2009 at 8:51 AM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
Answering to Frank here too:
We can suppose that a program that works with Jython, can safely use jython versions in Requires-Python,
unless it's possible for a given program to run on CPython *and* Jython and that it's impossible to use a common MAJOR.MINOR version ?
I think it will be very rare to find a program that works on both but only on different MAJOR.MINOR versions. It is *possible* - for example, we have an ast.py in Jython 2.5 even though CPython does not get this until 2.6 (ast.py as a replacement for pyc bytecode manipulation was just too compelling for us to ignore).
So do you think Requires-Python is good enough in general as it is described now, and that this case you mention can be handled by some code at install time, raising an error in case the conditions are not met ? Tarek
Tarek Ziadé wrote:
Hello
I've update PEP 345 with a first draft about the markers,
Thanks for adding this. One detail to add: python_full_version = sys.version.split()[0] This is important, since a package may well only support Python 2.5 starting with patch level release 2.5.2 and python_version only includes the major.minor version information.
PEP 390 is being reworked accordingly, but I guess we can have a new round of comments on PEP 345 and PEP 386, as they can be accepted and added in Python independently from the other PEPs.
There's also a "Requires-External" field that was added in the first update of 345, that we need to discuss.
The idea of this field is to be able to define a non-Python dependency in the metadata. It's based on a list stored and managed at PyPI.
Values could be things like "libxslt", "libpng", etc..
Am I right in understanding this as informational field only ? Different systems have different ways of naming such external dependencies, so it's unlikely that we can come up with our own little standard set of names for everything, e.g. you could use any of these names for a dependency on zlib and its header files: "zlib", "libz", "zlib-devel", "zlib-dev". It is also not clear where to draw the line and how to manage multiple mentions with slightly different focus, e.g. would you have both "zlib" and "zlib-devel" (extensions may require the binary and/or the lib and header files), or would "zlib" include the header files dependency ? Given the complexity this adds, I'm not sure whether it's worth trying to come up with a fixed list of names for external dependencies.
Last, "Requires-Python" is introduced to define the version of Python. I am not sure this is required anymore since Martin has added a Trove classifier for this. But in the meantime, this is stronger than a "simple" classifier I think.
This may be useful for cases like the one mentioned above (patch level requirements), which are not covered by the trove classifiers. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 16 2009)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M.-A. Lemburg wrote:
Tarek Ziadé wrote:
Hello
I've update PEP 345 with a first draft about the markers,
Thanks for adding this.
One detail to add:
python_full_version = sys.version.split()[0]
This is important, since a package may well only support Python 2.5 starting with patch level release 2.5.2 and python_version only includes the major.minor version information.
PEP 390 is being reworked accordingly, but I guess we can have a new round of comments on PEP 345 and PEP 386, as they can be accepted and added in Python independently from the other PEPs.
There's also a "Requires-External" field that was added in the first update of 345, that we need to discuss.
The idea of this field is to be able to define a non-Python dependency in the metadata. It's based on a list stored and managed at PyPI.
Values could be things like "libxslt", "libpng", etc..
Am I right in understanding this as informational field only ?
Yes. The primary consumers will be OS packagers, who will map them onto their own package names. As with other metadata they care about, we hope that the packagers will suggest packages to make these names "uniform" acrrss Python distributions. I imagine there will be some jockeying among them to find the "common" name for such things, which they will then need to map.
Different systems have different ways of naming such external dependencies, so it's unlikely that we can come up with our own little standard set of names for everything, e.g. you could use any of these names for a dependency on zlib and its header files: "zlib", "libz", "zlib-devel", "zlib-dev".
It is also not clear where to draw the line and how to manage multiple mentions with slightly different focus, e.g. would you have both "zlib" and "zlib-devel" (extensions may require the binary and/or the lib and header files), or would "zlib" include the header files dependency ?
Given the complexity this adds, I'm not sure whether it's worth trying to come up with a fixed list of names for external dependencies.
Again, this is mostly a place to put information as requested by the downstream packagers.
Last, "Requires-Python" is introduced to define the version of Python. I am not sure this is required anymore since Martin has added a Trove classifier for this. But in the meantime, this is stronger than a "simple" classifier I think.
This may be useful for cases like the one mentioned above (patch level requirements), which are not covered by the trove classifiers.
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksBZJAACgkQ+gerLs4ltQ7MuACeNPPxDLG+6bqQwxKxqhYfIQo9 js8AmwZy/Du9lMMoPmptzJBk7zfIVVEn =dhZl -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tres Seaver wrote:
M.-A. Lemburg wrote:
Tarek Ziadé wrote:
Values could be things like "libxslt", "libpng", etc.. Am I right in understanding this as informational field only ?
Yes. The primary consumers will be OS packagers, who will map them onto their own package names. As with other metadata they care about, we hope that the packagers will suggest packages to make these names
- --------------------------------------^ s/packages/patches/
"uniform" acrrss Python distributions. I imagine there will be some jockeying among them to find the "common" name for such things, which they will then need to map.
Dang muscle memory typed it for me. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksBdV0ACgkQ+gerLs4ltQ5UYQCg20vlmpBjAFdKeaUuNPOjyKaF bnUAoMn43mmuYsem98rpis7GzEYmGBfb =YuMe -----END PGP SIGNATURE-----
[Tres Seaver, 2009-11-16]
Values could be things like "libxslt", "libpng", etc..
Am I right in understanding this as informational field only ?
Yes. The primary consumers will be OS packagers, who will map them onto their own package names. As with other metadata they care about, we hope that the packagers will suggest packages to make these names "uniform" acrrss Python distributions. I imagine there will be some jockeying among them to find the "common" name for such things, which they will then need to map.
How about putting there what we (distro maintainers) can pass to ctypes.util.find_library()? It would be great if there would be another field for build dependencies, though. F.e. enchant extension required enchant headers to build enchant.so (so libenchant-dev package was required at build stage), but now it uses ctypes only and enchant.h is not needed at all. Previously I used ldd (or dpkg-shlibdeps to be exact) to get runtime dependencies from .so extension (so once I figured out the right build dependencies, runtime dependencies were generated automatically), now I use: from ctypes.util import find_library; print find_library("enchant") to generate right depenencies, but I had to read the sources to figure out what to pass to find_library. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Piotr Ozarowski wrote:
[Tres Seaver, 2009-11-16]
Values could be things like "libxslt", "libpng", etc.. Am I right in understanding this as informational field only ? Yes. The primary consumers will be OS packagers, who will map them onto their own package names. As with other metadata they care about, we hope that the packagers will suggest packages to make these names "uniform" acrrss Python distributions. I imagine there will be some jockeying among them to find the "common" name for such things, which they will then need to map.
How about putting there what we (distro maintainers) can pass to ctypes.util.find_library()?
How cross platform is that? Chris
On Tue, Nov 17, 2009 at 8:32 PM, Chris Withers <chris@simplistix.co.uk> wrote:
Piotr Ozarowski wrote:
[Tres Seaver, 2009-11-16]
Values could be things like "libxslt", "libpng", etc..
Am I right in understanding this as informational field only ?
Yes. The primary consumers will be OS packagers, who will map them onto their own package names. As with other metadata they care about, we hope that the packagers will suggest packages to make these names "uniform" acrrss Python distributions. I imagine there will be some jockeying among them to find the "common" name for such things, which they will then need to map.
How about putting there what we (distro maintainers) can pass to ctypes.util.find_library()?
How cross platform is that?
near none. I don't see much point in a field for this feature: that's a typical example where every os vendor is different, and it would bring more confusion that it worth IMHO. If there is a need for this feature within tools like buildout or pip, I think having a wrapped, fake python package for each library works better (and is actually portable). For helping OS integrators, I think a readme for packagers is as helpful. cheers, David
On Tue, Nov 17, 2009 at 1:56 PM, David Cournapeau <cournape@gmail.com> wrote:
On Tue, Nov 17, 2009 at 8:32 PM, Chris Withers <chris@simplistix.co.uk> wrote:
Piotr Ozarowski wrote:
[Tres Seaver, 2009-11-16]
Values could be things like "libxslt", "libpng", etc..
Am I right in understanding this as informational field only ?
Yes. The primary consumers will be OS packagers, who will map them onto their own package names. As with other metadata they care about, we hope that the packagers will suggest packages to make these names "uniform" acrrss Python distributions. I imagine there will be some jockeying among them to find the "common" name for such things, which they will then need to map.
How about putting there what we (distro maintainers) can pass to ctypes.util.find_library()?
How cross platform is that?
near none. I don't see much point in a field for this feature: that's a typical example where every os vendor is different, and it would bring more confusion that it worth IMHO.
I agree. And I can think about a few scenarii where the names managment at PyPI will be a nightmare. The PyPI manager will have to decide unilaterally the names to keep, the names to change, and he will need to maintain aliases for names that points to the same lib, to make both camps happy, and possibly keep backward compatibilities for those names. I am proposing to remove the Requires-External completely from PEP 345, unless someone wants it badly. (And he/she will need to go into greater details in these scenarii) Tarek
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tarek Ziadé wrote:
near none. I don't see much point in a field for this feature: that's a typical example where every os vendor is different, and it would bring more confusion that it worth IMHO.
I agree.
And I can think about a few scenarii where the names managment at PyPI will be a nightmare.
The PyPI manager will have to decide unilaterally the names to keep, the names to change, and he will need to maintain aliases for names that points to the same lib, to make both camps happy, and possibly keep backward compatibilities for those names.
I am proposing to remove the Requires-External completely from PEP 345, unless someone wants it badly. (And he/she will need to go into greater details in these scenarii)
- -1. I don't see a problem keeping it: it is "advisory" only. PyPI is not a consumer of this field, and should *not* be doing any enforcement / normalization / mapping of its values. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksC0uUACgkQ+gerLs4ltQ55JQCbBDH7gyWpWvw4+Lp+43GYV0QN qwwAmgICi+HzQCj9lt44e1lRY143Dj/U =EN8s -----END PGP SIGNATURE-----
On Tue, Nov 17, 2009 at 5:44 PM, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tarek Ziadé wrote:
near none. I don't see much point in a field for this feature: that's a typical example where every os vendor is different, and it would bring more confusion that it worth IMHO.
I agree.
And I can think about a few scenarii where the names managment at PyPI will be a nightmare.
The PyPI manager will have to decide unilaterally the names to keep, the names to change, and he will need to maintain aliases for names that points to the same lib, to make both camps happy, and possibly keep backward compatibilities for those names.
I am proposing to remove the Requires-External completely from PEP 345, unless someone wants it badly. (And he/she will need to go into greater details in these scenarii)
- -1. I don't see a problem keeping it: it is "advisory" only. PyPI is not a consumer of this field, and should *not* be doing any enforcement / normalization / mapping of its values.
In that case, I am not sure to see what's the point of keeping an external reference registery at PyPI, as a free place where anyone can put anything. The only gain I was seeing it normalization. If no normalization is done, then a plain README.txt file with this info in the project itself is sufficient, or maybe making the field hold these (name, description, url) info directly. Tarek
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tarek Ziadé wrote: > On Tue, Nov 17, 2009 at 5:44 PM, Tres Seaver <tseaver@palladion.com> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Tarek Ziadé wrote: >> >>>> near none. I don't see much point in a field for this feature: that's >>>> a typical example where every os vendor is different, and it would >>>> bring more confusion that it worth IMHO. >>> I agree. >>> >>> And I can think about a few scenarii where the names managment at PyPI >>> will be a nightmare. >>> >>> The PyPI manager will have to decide unilaterally the names to keep, >>> the names to change, and he will need to maintain aliases for names >>> that points to the same lib, to make both camps happy, >>> and possibly keep backward compatibilities for those names. >>> >>> I am proposing to remove the Requires-External completely from PEP >>> 345, unless someone wants it badly. (And he/she will need to go into >>> greater details in these scenarii) >> - -1. I don't see a problem keeping it: it is "advisory" only. PyPI is >> not a consumer of this field, and should *not* be doing any enforcement >> / normalization / mapping of its values. > > In that case, I am not sure to see what's the point of keeping an > external reference registery at PyPI, > as a free place where anyone can put anything. The only gain I was > seeing it normalization. > > If no normalization is done, then a plain README.txt file with this > info in the project itself is sufficient, or maybe making the field > hold these (name, description, url) info directly. This isn't *about* PyPI: it is about putting the information in a standard place for downstream packagers (*they* requested it). PyPI should either ignore the field or just pass it through untouched: downstream packagers are going to examine the PKG_INFO file in the tarball they work with, and might write scripts which do the mapping of the machine-readable file to their own dependency names. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksC+ikACgkQ+gerLs4ltQ6C6wCcCjgmVQAh//TyqcKSMtfboZzg TKMAoLHMh/uWl6b8LzAGKx1i52Sm6TX2 =PfNw -----END PGP SIGNATURE-----
On Tue, Nov 17, 2009 at 8:31 PM, Tres Seaver <tseaver@palladion.com> wrote: [..]
If no normalization is done, then a plain README.txt file with this info in the project itself is sufficient, or maybe making the field hold these (name, description, url) info directly.
This isn't *about* PyPI: it is about putting the information in a standard place for downstream packagers (*they* requested it). PyPI should either ignore the field or just pass it through untouched: downstream packagers are going to examine the PKG_INFO file in the tarball they work with, and might write scripts which do the mapping of the machine-readable file to their own dependency names.
And again, that's why I don't see *any* benefit of having an external registery at PyPI. You say that PyPI should ignore it, but in the meantime, the "External References Registry" implies that we will manage and maintain, urls and descriptions for each one of those Requires-External value. How this is going to work ? Why can't I put everything in my setup.py in the first place ? I have to go to PyPI first, to add an entry with an url and a description, then get back to my package to add just the name ? What happens if the name is taken, but I don't want the url and the description someone already put there ? I'll just go for another name ? And the packagers will have to look to my PKG-INFO, *and* to the PyPI registery ? That registery thing at PyPI doesn't make sense as it is currently described in the PEP because it implies that the metadata that comes with a project distribution are *incomplete* and that you need to look into a registery in some website to complete them. Although, having a structured way to describe external dependencies in the metadata is interesting. That's why I said that 100% of the information could stay in PKG-INFO (==the metadata), instead of having to maintain something else at PyPI. Developers can add their things in it, and packagers look at them. So, that means that "Require-Dist" field would need the url and the description, besides the name, like I've suggested. Tarek
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tarek Ziadé wrote:
That's why I said that 100% of the information could stay in PKG-INFO (==the metadata), instead of having to maintain something else at PyPI.
Apoligies for misunderstanding: I thought you were arguing to remove the field from PKG-INFO. I'm fine with removing any mandate for a registry from the PEP. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksDFYEACgkQ+gerLs4ltQ7PdQCfep1dxMMWOFRECaFQ5rPHbvGc pEYAniAFT21xe5s4cCr3e+2+BEFXix7J =pffI -----END PGP SIGNATURE-----
On Tue, Nov 17, 2009 at 9:40 PM, Tarek Ziadé <ziade.tarek@gmail.com> wrote: [..]
That's why I said that 100% of the information could stay in PKG-INFO (==the metadata), instead of having to maintain something else at PyPI.
As discussed live with Tres, we agreed that the Requires-External field is enough, as it is defined now, and that we can remove the Registry stuff from PEP 345. Tarek
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tarek Ziadé wrote: > On Tue, Nov 17, 2009 at 5:44 PM, Tres Seaver <tseaver@palladion.com> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Tarek Ziadé wrote: >> >>>> near none. I don't see much point in a field for this feature: that's >>>> a typical example where every os vendor is different, and it would >>>> bring more confusion that it worth IMHO. >>> I agree. >>> >>> And I can think about a few scenarii where the names managment at PyPI >>> will be a nightmare. >>> >>> The PyPI manager will have to decide unilaterally the names to keep, >>> the names to change, and he will need to maintain aliases for names >>> that points to the same lib, to make both camps happy, >>> and possibly keep backward compatibilities for those names. >>> >>> I am proposing to remove the Requires-External completely from PEP >>> 345, unless someone wants it badly. (And he/she will need to go into >>> greater details in these scenarii) >> - -1. I don't see a problem keeping it: it is "advisory" only. PyPI is >> not a consumer of this field, and should *not* be doing any enforcement >> / normalization / mapping of its values. > > In that case, I am not sure to see what's the point of keeping an > external reference registery at PyPI, > as a free place where anyone can put anything. The only gain I was > seeing it normalization. > > If no normalization is done, then a plain README.txt file with this > info in the project itself is sufficient, or maybe making the field > hold these (name, description, url) info directly. This isn't *about* PyPI: it is about putting the information in a standard place for downstream packagers (*they* requested it). PyPI should either ignore the field or just pass it through untouched: downstream packagers are going to examine the PKG_INFO file in the tarball they work with, and might write scripts which do the mapping of the machine-readable file to their own dependency names. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksC/rsACgkQ+gerLs4ltQ4+rgCgiyIVoFCReG8KNE/BixtxCWH/ gOAAnjN8v8I4rS7MUiok3Xb64Lq89dW9 =OIBJ -----END PGP SIGNATURE-----
On Tue, Nov 17, 2009 at 11:44:26AM -0500, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tarek Ziadé wrote:
near none. I don't see much point in a field for this feature: that's a typical example where every os vendor is different, and it would bring more confusion that it worth IMHO.
I agree.
And I can think about a few scenarii where the names managment at PyPI will be a nightmare.
The PyPI manager will have to decide unilaterally the names to keep, the names to change, and he will need to maintain aliases for names that points to the same lib, to make both camps happy, and possibly keep backward compatibilities for those names.
I am proposing to remove the Requires-External completely from PEP 345, unless someone wants it badly. (And he/she will need to go into greater details in these scenarii)
- -1. I don't see a problem keeping it: it is "advisory" only. PyPI is not a consumer of this field, and should *not* be doing any enforcement / normalization / mapping of its values.
IMHO the only sane way of keeping the field is regarding it as a "readme" and hence just make it completely free form text to be interpreted by humans only. I'm +0 on removing it since the long description can probably describe this easier. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org
On Mon, Nov 16, 2009 at 11:55:44AM +0100, M.-A. Lemburg wrote:
Tarek Ziadé wrote: One detail to add:
python_full_version = sys.version.split()[0]
This is important, since a package may well only support Python 2.5 starting with patch level release 2.5.2 and python_version only includes the major.minor version information.
I still like hex(sys.hexversion) for this. IIRC this is what the docs recommend to use inside python code too for checking versions. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org
Floris Bruynooghe wrote:
On Mon, Nov 16, 2009 at 11:55:44AM +0100, M.-A. Lemburg wrote:
Tarek Ziadé wrote: One detail to add:
python_full_version = sys.version.split()[0]
This is important, since a package may well only support Python 2.5 starting with patch level release 2.5.2 and python_version only includes the major.minor version information.
I still like hex(sys.hexversion) for this. IIRC this is what the docs recommend to use inside python code too for checking versions.
Fine with me, but that format doesn't work too well with the (new) standard for distutils version numbers which is supposed to be used for these version comparisons. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 17 2009)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Tue, Nov 17, 2009 at 2:04 PM, M.-A. Lemburg <mal@egenix.com> wrote:
Floris Bruynooghe wrote:
On Mon, Nov 16, 2009 at 11:55:44AM +0100, M.-A. Lemburg wrote:
Tarek Ziadé wrote: One detail to add:
python_full_version = sys.version.split()[0]
This is important, since a package may well only support Python 2.5 starting with patch level release 2.5.2 and python_version only includes the major.minor version information.
I still like hex(sys.hexversion) for this. IIRC this is what the docs recommend to use inside python code too for checking versions.
Fine with me, but that format doesn't work too well with the (new) standard for distutils version numbers which is supposed to be used for these version comparisons.
+1 Using sys.hexversion would bypass the PEP 386-compatible standard we want to provide. (I am adding python_full_version in the PEP btw) Tarek
Tarek Ziadé wrote:
Last, "Requires-Python" is introduced to define the version of Python. I am not sure this is required anymore since Martin has added a Trove classifier for this.
I don't think Trove classifiers have anything to do with this. Otherwise, we could move *all* the requirements stuff into trove classification which buys us nothing more than having to maintain a huge list of trove classifiers. I like the idea of Requires-Python, but only because I don't see why Python can't just be specified in the equivalent of setuptools' install_requires and its ilk. Why can't python just be treated as another package on while a package my have a particular version dependency? Chris
Chris Withers wrote:
Tarek Ziadé wrote:
Last, "Requires-Python" is introduced to define the version of Python. I am not sure this is required anymore since Martin has added a Trove classifier for this.
I don't think Trove classifiers have anything to do with this. Otherwise, we could move *all* the requirements stuff into trove classification which buys us nothing more than having to maintain a huge list of trove classifiers.
I like the idea of Requires-Python, but only because I don't see why Python can't just be specified in the equivalent of setuptools' install_requires and its ilk.
Why can't python just be treated as another package on while a package my have a particular version dependency?
Perhaps because a package manager cannot go and resolve that dependency by installing another Python version for you ? ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 17 2009)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Tue, Nov 17, 2009 at 12:30 PM, Chris Withers <chris@simplistix.co.uk> wrote: [..]
I like the idea of Requires-Python, but only because I don't see why Python can't just be specified in the equivalent of setuptools' install_requires and its ilk.
Why can't python just be treated as another package on while a package my have a particular version dependency?
But it turns it into a chicken and egg problem: what happens if your add "python>3" in "Requires-Dist" (the equivalent of install_requires) ? Pip or easy_install is going to look for Python 3, and install it ? then install itself in Python 3 and relaunch itself ? I think Python is not to be treated as a package dependency, but as a specific pre-request that has to be met for your application to run. That's why it has to be specified separately from Requires-Dist. Tarek
Tarek Ziadé wrote:
On Tue, Nov 17, 2009 at 12:30 PM, Chris Withers <chris@simplistix.co.uk> wrote: [..]
I like the idea of Requires-Python, but only because I don't see why Python can't just be specified in the equivalent of setuptools' install_requires and its ilk.
Why can't python just be treated as another package on while a package my have a particular version dependency?
But it turns it into a chicken and egg problem: what happens if your add "python>3" in "Requires-Dist" (the equivalent of install_requires) ?
True. Oh well. Requires-Python it is then...
Pip or easy_install is going to look for Python 3, and install it ? then install itself in Python 3 and relaunch itself ?
That's what buildout does is you specify a version of itself ;-) Chris
On Tue, Nov 17, 2009 at 11:49 +0000, Chris Withers wrote:
True. Oh well. Requires-Python it is then...
Can anyone add that proposal to the wiki so it won't be forgotten? Furthermore it can be seen by people that try to get an overview of the changes that might be integrated. http://wiki.python.org/moin/Distutils/DiscussionOverview TIA! -- .''`. Wolodja Wentland <wentland@cl.uni-heidelberg.de> : :' : `. `'` 4096R/CAF14EFC `- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC
On Tue, Nov 17, 2009 at 2:20 PM, Wolodja Wentland <wentland@cl.uni-heidelberg.de> wrote:
On Tue, Nov 17, 2009 at 11:49 +0000, Chris Withers wrote:
True. Oh well. Requires-Python it is then...
Can anyone add that proposal to the wiki so it won't be forgotten? Furthermore it can be seen by people that try to get an overview of the changes that might be integrated.
It's already in PEP 345
On Tue, Nov 17, 2009 at 14:20 +0100, Tarek Ziadé wrote:
On Tue, Nov 17, 2009 at 2:20 PM, Wolodja Wentland It's already in PEP 345
Even better :-D -- .''`. Wolodja Wentland <wentland@cl.uni-heidelberg.de> : :' : `. `'` 4096R/CAF14EFC `- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC
On Tue, Nov 17, 2009 at 2:25 PM, Wolodja Wentland <wentland@cl.uni-heidelberg.de> wrote:
On Tue, Nov 17, 2009 at 14:20 +0100, Tarek Ziadé wrote:
On Tue, Nov 17, 2009 at 2:20 PM, Wolodja Wentland It's already in PEP 345
Even better :-D
Although, the wiki page you set up is great to gather the ideas being discussed, so if Requires-Python as it is now in the PEP 345 turns out to be controversial, we can write down the various options in the wiki Tarek
participants (11)
-
Chris Withers -
David Cournapeau -
David Lyon -
Floris Bruynooghe -
Frank Wierzbicki -
Kevin Teague -
M.-A. Lemburg -
Piotr Ozarowski -
Tarek Ziadé -
Tres Seaver -
Wolodja Wentland