[Python-Dev] "Absolute" paths in PEP 376 RECORD files

[Tarek Ziadé]

On Thu, Jul 9, 2009 at 9:09 PM, P.J. Eby<pje at telecommunity.com> wrote:
> At 02:46 PM 7/9/2009 -0400, Tres Seaver wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Nick Coghlan wrote:
>> > P.J. Eby wrote:
>> >>>  Also,
>> >>> why should the RECORD file be generated at all by bdist* commands?
>> >> bdist commands that use "install --root" will get it as a side effect,
>> >> so they don't have to do anything special.  They needn't even generate
>> >> the PREFIXES, if PREFIXES is also generated by "install --root", and
>> >> omits the root from the prefixes written.  In other words, most bdist
>> >> tools wouldn't change.  bdist_wininst and bdist_msi might need to
>> >> regenerate PREFIXES at actual installation time, but AFAIK those are
>> >> the
>> >> only ones.  (And the spec would allow for the possibility that a
>> >> PREFIXES file can be incorrect.)
>> >
>> > I haven't seen any suggestions for handling non-relative paths that are
>> > cleaner than this. The distutils based list that Tarek posted also gives
>> > a good "starter set" of supported entries in the PREFIXES file:
>> >
>> > PURELIB=<path>
>> > PLATLIB=<path>
>> > HEADERS=<path>
>> > SCRIPTS=<path>
>> > DATA=<path>
>> >
>> > The question then would be whether relative paths should be handled
>> > directly in the RECORD file (as in the current PEP) or by writing a "."
>> > into PREFIXES to indicate relative paths.

I like the idea of a separated PREFIXES file, then using variables in
the RECORD file.
While this doesn't change anything code-wise, we can keep that way two
csv-browsable files.

>>
>> Per discussion with Matthias Klose, it would be useful to split out the
>> following prefixes for "special" kinds of data:
>>
>> - - docs
>> - - i18n / locales
>
> Unfortunately, the distutils don't currently have a way to specify these.  I
> think we'll need to use only the ones that are distutils install targets at
> first, but of course the format is extensible.
>
> OTOH, one supposed that at least the 'data_files' setup argument could be
> enhanced to allow a data type flag, that would then be used as a prefix name
> for those files, with a fallback to the DATA prefix if there isn't one
> specified.  But that's something that will require tagging support in the
> install_data command.  As it is, refactoring the distutils to track prefixes
> for the RECORD file is probably going to be...  challenging.  ;-)

yes, if we want to provide extensibility, a new prefix that is used by
a developer in its distribution
will have to be provided for all platforms, so distutils can build the
proper RECORD file
by querying the path that corresponds to the platform it runs on.

In other words, if a data type flag is provided in data_files, the
list of absolute paths
per key in distutils.command.install.INSTALL_SCHEMES  should be
provided with it.

This could be done with a new 'extra_prefixes' argument for example,
provided with the 'data_files',
that would let distutils extend INSTALL_SCHEMES on the fly

setup(
    ...
    data_files={'i18n': ['en.po', 'fr.po']},
    extra_prefixes={'i18n': {'unix_prefix': '/somewhere',
                                         'mac': '/Application/right/here'}
 ...
  )

But then data_files could maybe be left alone (that's specific to
'data' after all)
and a new option created.

In any case that would be a great solution to avoid 'wild absolute
path' and be sure
that the developer thinks about where each fil of his distrbution
goes, depending
on the plaftorm.

While debian packagers and al might not use it to re-package python
distributions in debian
packages, I am sure they will like it very much because it helps
identifiying what the developer
wanted to do with these "data" files.