Beyond wheel 1.0: more fine-grained installation scheme
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..., 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
participants (4)
-
Ben Finney
-
Daniel Holth
-
David Cournapeau
-
Nick Coghlan