Feedback request: next generation of upstream Python metadata

[Bohuslav Kabrda]

----- 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.