[Distutils] Platform specific destinations in wheel files?

[Nick Coghlan]

On 28 December 2013 06:02, Chris Barker <chris.barker at noaa.gov> wrote:
> On Tue, Dec 24, 2013 at 2:28 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> > But that concept doesn't work on all platforms, so we should be careful
>> > about isolating it.
>>
>> Encapsulating that assumption is why I think the "gnu" nesting is
>> justified. There are layout expectations inherent in the autoconf directory
>> design that just don't make sense on Windows, so any package expecting them
>> is going to be a bit quirky if installed on Windows.
>
> I'm confused now as to what has been proposed or being discussed, or...
>
> I _thought_ that this thread started with a proposal that package authors
> would do something like specifying a file hierarchy for the stuff they are
> delivering:
>
> /bin/some_scripts
> /share/some_data
> /man/some_docs
> ....
>
> then at installation time, the python distro would decide where to copy all
> that.
>
> But this would beb worthless on non-gnu systems and would require:
>  1) package writer to write three or four versions
>  2) wheels to be platform-dependent unnecessarily.
>
> So my suggestion was to define the various locations where stuff may need to
> be installed at a higher level:
>
> place_to_put_top_level_scripts
> place_to_put_documentation
> place_to_app_data
> place_to_put_user_configuration_files
> place_to_put_user_system_configuration_files
> .....
>
> Then the python distro would map these to actual paths at install time: gnu
> systems would map the gnu locations, Windows to Windows-appropriate
> locations, OS-X to OS-X locations, etc.... This wold also allow python
> distros like Anaconda or macports python, or ??? to do their own thing,
> which may not be putting everything in /usr/local, or ...
>
> That may be what you had in mind, but I got confused.

There's no concrete proposal on the table at this point in time - just
an acknowledgement that this is a use case the wheel format doesn't
yet handle (sdists can handle it due to the way that setuptools
handles the data_files option).

However, any concrete proposal will likely use the GNU structure as
the basis for "kinds of files" rather than inventing a new
Python-specific naming scheme (or make an extremely compelling case
for inventing our own custom scheme), and on Windows and Mac OS X,
many of those will likely just map to dumping things in the app
directory (or the application data directory in the case of Windows).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia