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
> * 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  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
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
The next draft should be posted to python.org
and distutils-sig some
time this week.
Red Hat Infrastructure Engineering & Development, Brisbane
Test Automation Team Lead
Beaker Development Lead (http://beaker-project.org/
PulpDist Development Lead (http://pulpdist.readthedocs.org