[Python-modules-team] Bug#814069: python-six-whl and python-pip-whl: error when trying to install together

[Barry Warsaw]

On Feb 08, 2016, at 10:51 AM, Colin Watson wrote:

>Looks like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813399, but
>more of the same.  Barry, shouldn't you be doing something like
>"python-six-whl (<< 1.10.0+)", rather than these sketchy <= dependencies
>on specific packaging revisions that are going to break when we do
>something innocuous in six?
>
>The whole way this devendoring is handled seems very very sketchy
>anyway.  I take it that you're trying to ensure that pip has
>exactly-versioned wheels available even when (e.g.) six moves on to a
>newer upstream version?  In that case, I suggest finding a way to ship
>the necessary wheels in a directory private to pip instead of in
>/usr/share/python-wheels/.  We really shouldn't be deliberately shipping
>the same file in two different packages for more than just temporary
>transitional purposes.
>
>> Here is a list of files that are known to be shared by both packages
>> (according to the Contents file for sid/amd64, which may be
>> slightly out of sync):
>> 
>>   /usr/share/python-wheels/six-1.10.0-py2.py3-none-any.whl
>> 
>> This bug has been filed against both packages. If you, the maintainers of
>> the two packages in question, have agreed on which of the packages will
>> resolve the problem please reassign the bug to that package. You may then
>> also register in the BTS that the other package is affected by the bug.  
>
>I would be inclined to argue that this path clearly belongs to the
>python-six-whl package.  Barry, do you agree with me reassigning this
>bug to python-pip-whl?

-whl packages really only exist for pip and virtualenv.  As per Debian Python
policy, they shouldn't be used for anything else in the archive.  It used to
be that the only way we could provide those .whl files was to build them when
we built the dependent packages, thus we had to add python-six-whl and others.

But now we have dirtbike, which is a tool to turn .deb provided packages back
into wheels, so pip and virtualenv build whatever they need using dirtbike in
their own d/rules files, and have Built-Using headers to at least document
this; or at least *did* - it looks like some things got lost or mis-merged
from an earlier branch :(

So where we ultimately want to end up is that python-six-whl and the others go
away.  Instead, we'll have only python-pip-whl and another -whl package in
virtualenv to provide a few additional requirements.  I haven't uploaded or
file bugs for the appropriate changes in the dependent packages yet.  I
thought I had everything working locally and ready to go, but I've run into a
few snafus which I'm still working out.

Anyway, that's the plan.  As you mention, this really is a transitional period
and I thought it would go more smoothly.  /usr/share/python-wheels will not
have two paths owned by two different packages once this is done.  Debian
Python Policy has been updated in bzr but not yet pushed out (there are other
unrelated changes pending).

You're right Colin, that this bug really belongs in pip and I think it should
be duped to #813399; which I closed over the weekend, but maybe not
correctly.  You might be right about the << dependencies, in which case, let's
keep this bug (#814069) as a separate bug, but move it to python-pip.

Hopefully that makes sense.  Apologies for all the brokenness I've introduced.
I had some work priorities that unfortunately interrupted this transition, but
I'll be working only on this transition now until it's all fixed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/python-modules-team/attachments/20160208/faeca879/attachment.sig>