Just an idea... suppose that instead of using "real" absolute paths
in the RECORD file for non-local files (scripts, data, etc) we
changed the format to include a "prefix" field, containing something
like LIBDIR, SHARE, SCRIPTS, etc., ala bdist_wininst internals?
Also, we could include a separate (optional) PREFIXES file defining
what those locations translated to at install time. Dumb bdists
would still have their build paths there (or delete the file before
packaging, or use real paths instead of the --root prefixed versions).
Upside: relocation can be detected and handled, RECORD remains
cross-platform, and bdists are ok.
Downside: more complex API required to read/manipulate paths and
delete files, since you need to be able to check that you have the
right prefixes, and may have to ask the user for a prefix you don't
recognize, if the default in PREFIXES doesn't match.
Thoughts?
(Also, as a special case, any file that's actually installed to
LIBDIR or a subdirectory thereof (even if it's technically a "data"
file or script), will probably need to be designated under LIBDIR
prefix to prevent runtime breakage in the event any system package
maintainers are tempted to use RECORD files as a way of forcing a HFS
conformance. These are installation prefixes, *not* content types.)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
