[Distutils] Platform specific destinations in wheel files?

[Nick Coghlan]

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 at gmail.com   |   Brisbane, Australia