With the Python 3.4 feature freeze behind us, I've started looking at doing a new update of the draft metadata 2.0 docs. Vaguely related to that are the recent discussions about being able to publish an FHS compliant daemon like cobblerd as a wheel file - using Python specific formats to define the layout of full applications, not just libraries. Currently, all of the paths defined in sysconfig schemes aim to be platform neutral. However, this means that some platform specific concepts can't easily be handled by the wheel format - the "data" scheme can sort of handle it, but it isn't particularly intuitive, and doesn't inherently reflect the platform dependent nature of the layout being defined. I'd generally been resisting the idea of supporting this (since I favour interoperating with system packaging tools where appropriate over attempting to replace them entirely), but in this case I'm starting to think it may be necessary to support these layouts in the next version of the wheel format in order to *also* support automated conversion of upstream projects to policy compliant system packages. As a reminder, here are the currently defined Python specific directories relevant to wheel files: platlib: directory for site-specific, platform-specific files. purelib: directory for site-specific, non-platform-specific files. include: directory for non-platform-specific header files. platinclude: directory for platform-specific header files. And these are the generic directories that aren't necessarily Python specific: scripts: directory for script files. data: directory for data files. This is still only a half-baked idea at this point, but I'm currently leaning towards keeping the "<name>.data" sysconfig subdirectories in the wheel format cross platform (and somewhat Python specific), and adding a new "<name>.app" subdirectory in parallel. A wheel that had content in "app" would be inherently platform specific - you wouldn't be permitted to use the new directory in a cross-platform wheel file. The defined subdirectories of app would also be platform specific. All POSIX systems would at least support the "fhs" subdirectory. For a system install, this would map to "/", for a virtualenv install it would map to the root of the virtualenv and for a user install it would map to "~/.local". I'm not sure what other subdirectories would be appropriate for Windows or Mac OS X, although I expect being able to install into Program Files and Application Data would be interesting for Windows apps, and into an application folder for Mac OS X. It's really the potential for FHS support that drives my interest in the idea, but if we're going to do something like this at all, it shouldn't be POSIX specific. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia