[Python-Dev] PEP 376 - Open questions

[Tarek Ziadé]

On Tue, Jul 7, 2009 at 10:33 AM, Paul Moore<p.f.moore at gmail.com> wrote:
> 2009/7/7 Tarek Ziadé <ziade.tarek at 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-files
>
> 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)