Hi all,
The initial draft of Python's next generation metadata standard is up on python.org:
PEP 426 (metadata 2.0): http://www.python.org/dev/peps/pep-0426/ PEP 440 (versioning): http://www.python.org/dev/peps/pep-0440/
The rationale for many of the changes is at the end of each PEP, along with some comments on features that I have either rejected or deliberately chosen to defer to the next revision of the metadata (at the earliest).
Those with BitBucket accounts may also comment inline on the drafts here:
PEP 426: https://bitbucket.org/ncoghlan/misc/src/05d3586464b10d6a04a35409468269d7c89a... PEP 440: https://bitbucket.org/ncoghlan/misc/src/05d3586464b10d6a04a35409468269d7c89a...
The distutils-sig thread is here: http://mail.python.org/pipermail/distutils-sig/2013-May/020863.html
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
Cheers, Nick.
----- Original Message -----
Hi all,
The initial draft of Python's next generation metadata standard is up on python.org:
PEP 426 (metadata 2.0): http://www.python.org/dev/peps/pep-0426/ PEP 440 (versioning): http://www.python.org/dev/peps/pep-0440/
Hi Nick, this looks very good. I particularly like the idea of having dev-requires separated from build-requires - I have already packaged some libraries that just had "requirements.txt" with a huge list, out of which half were just development tools not actually needed during building/testing. test-requires is even better in this, since it might allow us to automatically generate specfiles (with pyp2rpm for example) with something like
%global with_test 1
%if 0%{?with_test} BuildRequires: python-foo %endif
... This may prove to be a great improvement for local work with package - e.g. you may want to rebuild them without running tests/drawing in the test deps.
The "Provides" section seems to be something that we might need to add to guidelines - this would probably map to "Provides: python-foo", although we should first think of the RPM/Yum implications of that.
<snip>
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?)
Thanks a lot, Slavek.
Cheers, Nick.
-- Nick Coghlan Red Hat Infrastructure Engineering & Development, Brisbane
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
python-devel@lists.fedoraproject.org
-
Bohuslav Kabrda -
Nick Coghlan