[Distutils] Add additional file categories for distutils, setuptools, wheel

[Nick Coghlan]

On 18 April 2015 at 21:31, Daniel Holth <dholth at gmail.com> wrote:
> On Sat, Apr 18, 2015 at 7:26 PM, Paul Moore <p.f.moore at gmail.com> wrote:
>> Examples of where this functionality is needed would be great. I'm
>> worried that we'll over-engineer a solution otherwise.
>
> Remember when distutils-sig didn't believe that Windows users actually
> lacked compilers?
>
> graphite-web and carbon are two examples of Python applications with
> lots of data files, that want to install config files into an obvious
> place so you can edit them and get the applications up and running.
> Because Python packaging has such terrible support for applications
> that are not libraries, it's unnecessarily hard to get these packages
> up and running -- especially if you want to put them in a virtualenv.

It's a fairly standard practice in Fedora/RHEL/CentOS to use setup.py
to define the build process in the RPM spec file, even if the package
itself is never distributed via the upstream package index (e.g.
beaker-project.org is built that way, as is pulpproject.org).

Fedora's packaging policy for redistribution of upstream Python
projects also switched last year to favour using "pip install" in the
RPM build process over invoking "setup.py install" directly.

Historically, all the "extra bits" needed to comply with FHS have
lived in the spec file, independently of the upstream packaging
system, requiring changes in two places for certain kinds of packaging
modifications, and frequently rendering the projects undeployable in a
virtual environment for no good reason.

The benefit of Daniel's proposal is that it should make it feasible to
modify many of these projects to be virtualenv friendly, and then
*automate* the process of generating FHS policy compliant downstream
packages. That will be a big step towards "package for PyPI, get your
conda/Nix/Debian/Fedora packaging for free", so it feeds directly into
my own interests in streamlining the redistribution pipeline in
Fedora.

>From a Windows perspective, I believe this change mostly has the
potential to make services that were previously Linux-only solely for
packaging related reasons available on Windows as well. However, there
may also be an opportunity to better automate the process of
generating wix-based installers from PyPI packages (see
http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/add_a_file.html)
rather than generating Windows installers directly (if I understand
the tooling correctly, introducing wix into that process should offer
the same kind of potential for better platform integration that
integrating with distro package managers offers on Linux).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia