On Thu, Jul 9, 2009 at 9:09 PM, 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.
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.