Just implement it. You could also try editing wheel's own proof of concept installer. https://bitbucket.org/pypa/wheel/src/tip/wheel/install.py?at=default#cl-246
On Tue, Apr 14, 2015 at 3:20 PM, David Cournapeau <courn...@gmail.com> wrote: > > > 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
