----- 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
--
Regards,
Bohuslav "Slavek" Kabrda.