Open Stack

On 16 April 2015 at 07:58, Clint Byrum <clint at fewbar.com> wrote:
> Excerpts from Sean Dague's message of 2015-04-15 06:50:11 -0700:
>> == End game?
>>
>> *If* pip install took into account the requirements of everything
>> already installed like apt or yum does, and resolve accordingly
>> (including saying that's not possible unless you uninstall or upgrade
>> X), we'd be able to pip install and get a working answer at the end. Maybe?
>>
>> Honestly, there are so many fixes on fixes here to our system, I'm not
>> sure even this would fix it.
>>
>
> This also carries a new problem: co-installability. If you get deep into
> Debian policy, you'll find that many of the policies that make the least
> sense are there to preserve co-installability. For instance, Node.js
> caused a stir a while back because they use '/usr/bin/node' for their
> interpreter. There was already an X.25 packet-radio-thing that used that
> binary and was called node, and so the node.js maintainers simply said
> "Conflicts: node". This causes problem though, as now you can't have an
> X.25 packet-radio-thing that also uses node.js.
>
> Right now users can go ahead and violate some stated requirements after
> they've run tests and verified whatever reason the conflict is present
> doesn't affect them, by simply ordering their requirements. It's not
> awesome, but it _does_ work. Without that, pypi suddenly is sectioned
> off into islands the moment a popular library narrows its requirements.

There's already --no-deps to give folk an escape clause in the pip
world. The coinstallability problem is not created by the tool
observing it - its just made explicit.

And honestly as a user, I prefer 'no you can't break the other thing
you installed' to 'oops, I did it again'.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud