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. ;-)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4