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