On Tue, Apr 14, 2015 at 9:27 AM, Daniel Holth <dho...@gmail.com> wrote:

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

$prefix would be set to sys.prefix and $eprefix to sys.exec_prefix to
handle automatically.

Should I work on a PEP for wheel 2.0, or a pip implementation first  ?


> IIRC extra package-1.0-data/* directories in wheel are undefined.


pip will actually fail to install any wheel with an undefined directory
package-1.0-data/* (unfortunately this is not detected before installing,
so it ends up with a half installed package).

David


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

Reply via email to