[Distutils] PEP-459 feedback from openSUSE packaging

[Sascha Peilicke]

Hi guys,

a colleague of mine hinted me to Nick's plea for feedback on various PEPs from 
other distros perspectives. 

I will provide some general remarks first and latter comment at least PEP-459. 
So for openSUSE (and SLES), we automate Python package generation as much as 
possible. For that we parse the metadata as found on PyPI and maul the source 
distribution (yeah, the tarball) for every usable bit. The latter is necessary 
to properly install files such as README, AUTHORS, LICENSE(.txt,...). We also 
use it to grep for '*test*' files to decide if it'S worth generating a RPM 
%check section.

Some modules do add 'package_data'. That's usually helpful since it goes 
straight into %python_sitelib. For the files mentioned above, we have 
'data_files'. Not only is it seldomly used, it's almost universally done 
wrong. Simply because every distro differs on where to put these files to.

A different cause of woe are install_requires / requires vs. setup_requires 
vs. test_require. Some people use 'requires', which is mostly documentation 
and lots of people put _everything_ in install_requires. From a distribution 
viewpoint, you have different sets of requirements:

 - build-time
   + optionally doc-requires
   + optionally test-requires
 - run-time

So setup_requires / test_require can be used to generate semi-accurate 
BuildRequires: $bla RPM spec tags. But as said, few people use them and less 
do it correct. Maybe because 'setup_requires' doesn't specificy build-time 
reqs but 'setuptools-invocation-time' reqs (which is sth. different). Also, we 
simply use 'install_requires' as both 'Requires:' (runtime) and 
'BuildRequires:' (build-time). But that's a cludge. For example, projects 
include 'Sphinx' in install_requires. What they meant is "if you want to build 
docs, use Sphinx". What they specified is "you always need it". Thankfully, 
the advent of pep allows us to check requirements.txt and test-
requirements.txt. The latter are usually build-time (for the RPM %check 
section). I guess I have to dig into the other PEPs first to see if this 
really changed before being able to comment on that any further.

In general, the other metadata is good enough (except 'license', see below), 
'name', 'version', 'upstream_url' and 'description' are used for their 
respective RPM spec counterparts. 'long_description' is used for '%description 
$PKG_NAME'. The tarball download URL is used as 'Source0:'. All other metadata 
tags are ignored because we don't need them to build a RPM.


The 'license' metadata tag is causing the most issues for us. A perceived 50% 
just put "GPL" in there. Which GPL version? GPL-only or actually LGPL?. We 
have a legal crawler that tries to match the version from the source code but 
often it's becomes a manual task or needs a check with upstream. This tag is 
probably the least interesting for an upstream developer but the most 
important one for any distro that has a corporate legal entity somewhere in 
behind (I should say, sue-able entitity :-). So with regards to PEP-459 
specifically, I have specific recommendations for the license tag. Instead of 

        "This field SHOULD contain fewer than 512 characters and MUST contain 
fewer 
        than 2048.

        This field SHOULD NOT contain any line breaks."

I would propose:

        "This filed SHOULD contain a standardized license identifier as
         published by spdx.org."


SPDX-sytle license identifiers are short (less than 20 chars) and can be 
parsed automatically. They are meant to be unambiguous and cross-distro.
SPDX.org license tags are used extensively inside openSUSE and SLES and (to my 
knowledge) for Fedora and Debian too. That would be the single most 
interesting change I'd be interest in.

I hope this was helpful, feel free to bug me if you need further detail.
-- 
Mit freundlichen Grüßen,
Sascha Peilicke