Feedback request: next generation of upstream Python metadata

Nick Coghlan ncoghlan at redhat.com
Mon Jun 3 02:42:26 UTC 2013


On 05/31/2013 06:23 PM, Bohuslav Kabrda wrote:
>> Possible changes already being discussed:
>>
>> * Contact metadata:
>>       "type" -> "role"
>>       "individual" -> "contributor"
>>       Lose the "organization" type (allows orgs to be entered for any role)
>> * New top level field "distributes"
>>       Like "requires", but doesn't discourage version pinning
>>       Used for metapackages (like PyObjC)
>>       May map nicely to software collections
>>
>
> Could you elaborate a bit on the "distributes" field? (or is there a discussion about this somewhere in depths of distutils-sig?)

For the majority of dependency declarations, pinning an exact version is 
bad because it complicates security updates and software integration in 
general. So an earlier version of the PEP discouraged the notion in all 
fields, while technically allowing it.

However, it was pointed on distutils-sig [1] that if you're doing a 
metadistribution like PyObjC, then you really *need* version pinning - 
the onus is then on the developers of the metadistribution to do a new 
release with updated pinned versions whenever one of the 
subdistributions is updated with a new relevant release.

The addition of the "distributes" field was a way to support 
metadistributions, while still discouraging overly specific dependencies 
by default.

The exact spelling I am now looking at is to use 
"meta_requires/meta_may_require" for metadistribution (version pinning 
required) and "run_requires/run_may_require" for ordinary runtime 
dependencies (version pinning disallowed - you must *at least* use the 
prefix matching syntax that allows security updates for normal 
dependencies).

The next draft should be posted to python.org and distutils-sig some 
time this week.

Cheers,
Nick.

[1] http://mail.python.org/pipermail/distutils-sig/2013-May/020868.html

-- 
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane

Test Automation Team Lead
Beaker Development Lead (http://beaker-project.org/)
PulpDist Development Lead (http://pulpdist.readthedocs.org)


More information about the python-devel mailing list