On 19 April 2015 at 06:03, Paul Moore <[email protected]> wrote: > As a possible compromise, how about an approach where on Linux system > installs (or more accurately "those install schemes that are relevant > to the distribution packaging issue you described") the file > categories are installed into dedicated directories, as described. But > on other installs (virtualenvs, Windows, maybe OSX) the file > categories map to locations within package_data, so that they can be > accessed via normal mechanisms like loader.get_data. Application code > would need some support code to locate and read the files, but that's > true whether we go for this proposal or an "outside of site-packages" > scheme. Also, some things may even be better designated as "don't > install" in certain schemes (man files, for example, are pretty much > useless on Windows).
That's not a compromise, that's exactly what I want to see happen :) If it helps, one way to think of this is as a "file classification" system, where the packaging tools gain the ability to sort files into a richer set of categories, and its then up to installers to decide how those categories map to installation locations. For Windows, virtualenv, conda, nix, single file applications, etc, that's likely to be "self-contained application directory". For FHS, it will map to the on-disk categorisation expected by other tools. At the moment, because the FHS support is either hacked in, or managed externally, there's no way for installers to remap the installation targets for the "self-contained directory" use case. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
