[Distutils] PEP 345 update + RFC on "Requires-External" and "Requires-Python"

[Tres Seaver]

-----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,
>>
>> http://python.org/dev/peps/pep-0345/#environment-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 at 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-----