[Distutils] Beyond wheel 1.0: more fine-grained installation scheme

[Daniel Holth]

That's exactly what I would like to do. Then
distribution-1.0.data/sysconfdir/file in a wheel would install into
/etc/file in the default scheme, but would probably really wind up in
$VIRTUAL_ENV/etc/... for most of us web developers.

IIRC extra package-1.0-data/* directories in wheel are undefined. I
would have no problem putting fine-grained install schemes in 2.0 and
putting some of the other "wheel 2.0" features into wheel 3.
Incrementing the major version number would cause older pip to reject
the newer wheels, incrementing the minor version would produce a
warning.


On Tue, Apr 14, 2015 at 8:56 AM, David Cournapeau <cournape at gmail.com> wrote:
> Hi,
>
> I am splitting up the previous thread into one thread / proposal to focus
> the discussion.
>
> Assuming the basis of this proposal does not sound too horrible, I would
> make a proof of concept in a pip branch, so that we can flush out the
> details and then write an actual spec (I guess an updated wheel format would
> need a new PEP ?).
>
> The goal of this thread is to flush out a more fine-grained installation
> scheme, so that wheels can install files anywhere they want (at least within
> sys.prefix/sys.exec_prefix). I see two issues:
>
> 1. defining what the scheme should be
> 2. how should it be implemented in wheel: there are different trade-offs
> depending on whether we want this feature to be part of wheel format 1.* or
> 2.0.
>
> First, my understanding of the current situation:
>
> * per the wheel PEP 427, anything in the wheel top directory and not in
> distribution-1.0.data is installed in site-package
> * every top directory in distribution-1.0.data/ needs to be mapped to the
> scheme as defined in distutils install command.
> * pip rejects any directory in distribution-1.0.data/ which is not in the
> scheme from 2.
>
> My suggestion for a better scheme would be to use an extended version of the
> various default directories defined by autotools. The extension would handle
> windows-specifics. More concretely:
>
> # Suggested variables
>
> The goal of supporting those variables is to take something that is flexible
> enough to support almost any installation scheme, without putting additional
> burden on the developer. People who do not want/need the flexibility will
> not need to do anything more than what they do today.
>
> The variables I would suggest are every variable defined in
> https://github.com/cournape/Bento/blob/master/bento/core/platforms/sysconfig.py#L10,
> except for destdir which is not relevant here.
>
> On unix, the defaults follow autotools, and on windows, I mapped almost
> everything relative to sys.exec_prefix, except for the
> bindir/sbindir/libexecdir which map to "$prefix\Scripts".
>
> The $sitedir variable would need to be updated to use the value from
> distutils instead of the hardcoded value I put in that file as well.
>
> # How to handle the augmented scheme
>
> Right now, if I wanted to install something in say $prefix/share/doc, I
> would need to put it in distribution-1.0.data/data/share/doc, but this
> prevents use from handling different platforms differently.
>
> OTOH, this is the only way I can see to make the new scheme backward
> compatible with pip versions who would not understand the new scheme. I
> don't have a good sense of what we should do there, the core pip team may
> have a better sense.
>
> For now, I would be happy to just make a proof of concept not caring about
> backward compatibility in a pip branch. Does that sound like a workable
> basis to flush out an actual proposal ?
>
> thanks,
> David
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>