[Distutils] Platform specific destinations in wheel files?

[Chris Barker]

On Sat, Dec 21, 2013 at 2:57 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> compliant daemon like cobblerd as a wheel file - using Python specific
> formats to define the layout of full applications, not just libraries.
>


> 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.
>
>
hmm I tend to think, like you, that this isn't a problem wheel should
solve, but can also see the advantages...for the moment though talking
about how it would solve it may help clarify whether it should.

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.
>

is this necessary -- couldn't there be a way to provide the info in a
cross-platform way, and have it mapped to the platform specific locations
at install-time?



> 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".
>
>
then you explicitly put in "bin", sbin", "share", whatever?

This seems really klunky to me, and also forces platform dependence, and is
fundamentally tied to how posix does things....

Maybe it's not possible, but I suggest that we could pre-define the
locations that might be needed:

executables      (bin)
system_executables  (sbin)
user_executables  (./bin)
documentation (doc)
system_data_files (share ?)
user_data_files (./share )
app_configuration (/etc/appname)
user_app_configuration (./.app_name : ./Library )
....


This could end up being a pretty big list, but I think it could be finite.

Then at install-time, the installer maps these to the appropriate place on
the system.

It's a little different application, but wxWidgets does this pretty
successfully with wxStandardPaths.

-Chris













> 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
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20131223/a5875a32/attachment.html>