[Python-Dev] PEP 376 - Open questions

[Paul Moore]

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).
- 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.

Paul.