
On Thu, Sep 25, 2008 at 5:37 PM, David Cournapeau < david@ar.media.kyoto-u.ac.jp> wrote:
Matthias Klose wrote:
- setuptools has the narrow minded view of a python package being contained in a single directory, which doesn't fit well when you do have common locations for include or doc files. Does the fork accept patches to change such limitations and allowing FHS compliant packages?
Being self-contained is also a feature. People who package softwares outside distributions like this, as you are surely aware. Personally, I don't like that setuptools broke distutils install either (I prefer to manage my packages with stow, because setuptools broke too many times my setup for unknown reasons).
There should be the possibility to do both kind of installs (self-contained, or FHS compliant), but this is not so much a setuptools issue as a distutils issue, isn't it ? Dealing with this in distutils will be no fun, though...
Well, as long as things are clearly defined in the package, I guess FHS compliant package could be built with the same source tree. We could even install a distribution the FHS way or the self-contained way, as long as the tool knows what to put where. But that is already the case, a bit: For instance we have bdist_rpm, that builds rpms by mapping distutils metadata to rpm ones, The question is: starting with the current MetaData what would you miss to do a FHS installation ? Take a look at http://www.python.org/dev/peps/pep-0345/
cheers,
David _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/