On Tue, Jul 7, 2009 at 10:33 AM, Paul Moore<p.f.moore@gmail.com> wrote:
2009/7/7 Tarek Ziadé <ziade.tarek@gmail.com>:
Unless we define a "drive that contains the python installation" maybe, or the "Program Files" directory
would that make sense from a win32 point of view ?
I can't imagine that it would be useful in practice.
I know some people are writing to /etc to add their configuration file on the system,
So a real-world example under linux would be:
setup(..., data_files=[('/etc', ['myconf.cfg'])], ...)
That is basically how the examples are shown at:
http://docs.python.org/distutils/setupscript.html#installing-additional-file...
Thanks. Yes, that makes for a good example.
But this is already os-specific, and exists because distutils doesn't have a way (yet) to express systems locations independantly from their physical location, like what the RPM system does with %VARIABLES.
So another way to handle this maybe, like I have added with $PREFIX and $EXEC_PREFIX would be to nominate a list of variables that every python environment has (querying modules like sys) and let the developers use them as root locations for some files.
- sys.prefix - sys.exec_prefix - some elements returned by distutils.sysconfig.get_config_vars() (distutils.sysconfig queries the python Makefile amongst others) - ...
This adds extra complexity to the RECORD format, for little practical benefit that I can see.
From the POV of core distutils: - Windows users use bdist_wininst and/or bdist_msi, and absolute locations are a lost cause. - Presumably, some people use bdist_rpm (I don't know if there are other ways of creating RPMs).
They are othe ways to generate RPMs. There are also debian packaging scripts
- Everyone else uses setup.py install or a 3rd party tool. - PEP 302 style loaders aren't relevant as the core only uses the filesystem (not even zip files). - Only 3rd party tools will consume this data.
So, we need input from developers of 3rd party tools here. Phillip has stated the case for setuptools, from his POV having everything relative to the "install location" which is stored elsewhere (in the installer file) is fine. I'd like to know whether he needs "upwards-pointing" relative paths like ../../../../xx.py, but that's a small detail.
So - do any other potential users of the PEP 376 metadata want to speak up?
At the moment, it feels like we're designing things more or less in a vacuum.
I am CC'ing the people that worked with us for the versionning matters, they can speak from a Fedora and Ubuntu POV, I am also adding Jim for zc.buildout, he can provide precious input. (I am sorry if some people get the mail twice)