On 18 April 2015 at 21:31, Daniel Holth <[email protected]> wrote: > On Sat, Apr 18, 2015 at 7:26 PM, Paul Moore <[email protected]> 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 | [email protected] | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
