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