-----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-----