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

David Cournapeau cournape at gmail.com
Tue Apr 14 14:56:59 CEST 2015


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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150414/09bbf632/attachment.html>

More information about the Distutils-SIG mailing list