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

[P.J. Eby]

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