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. IIRC extra package-1.0-data/* directories in wheel are undefined. 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 <cournape@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..., 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

David Cournapeau <cournape@gmail.com> writes:

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.

This is a good direction to go, IMO. The expectations of Windows and *nix, when it comes to where files should be installed, are so disparate that abstracting the locations to functional labels which mean the same on all platforms will inevitably result in a lot of such labels. So, if we agree that such abstraction is worthwhile to pursue, the large set of labels (and perhaps even leaving it open to growing even more) should be embraced.

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

A point to note is that “people” in that statement can be different people with conflicting wants/needs. The developer who writes the Distutils metadata may want to have as little in there as possible, at the expense of flexibility in installation. The system integrator who needs to specify many different locations for the various files in the distribution will want the opposite. They still need to work on the same code base. So perhaps one consideration is that the distribution metadata should be extensible by the integrator, without extensive patches to the Python code; and the developer's code as written still finds the files in the resulting filesystem locations. Is that feasible?

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.

That looks like a lot of named locations. I think that is inevitable, as argued above.

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 ?

Looking forward to it. Thanks! -- \ “Teach a man to make fire, and he will be warm for a day. Set a | `\ man on fire, and he will be warm for the rest of his life.” | _o__) —John A. Hrastar | Ben Finney