Open Stack

On 22 January 2015 at 02:48, Chris Dent <chdent at redhat.com> wrote:
> On Wed, 21 Jan 2015, Sean Dague wrote:
>>>
>>> On the pip solver side, joe gordon was working on a thing to install a
>>> fixed set of packages by bypassing the pip resolver... not sure how
>>> thats progressing.
>>
>>
>> I think if we are talking seriously about bypassing the pip resolver, we
>> should step back and think about that fact. Because now we're producting
>> a custom installation process that will produce an answer for us, which
>> is completely different than any answer that anyone else is getting for
>> how to get a coherent system.

Actually buildout is precisely that today - you specify exact versions
and get them. pip's inability to duplicate that behaviour is one of
the reasons buildout is still a thing; bypassing the resolver to get
the same behaviour *for the same reasons!* isn't at all odd.
Undesirable perhaps - and we should work on pip upstream too - but not
odd.

> Agreed. Skipping the pip resolver will move OpenStack and friends further
> down into a weird world of its own rather than Python norms.

See above - I disagree. Python norms are -very- broad, and buildout
has a healthy ecosystem within Python web shops, for exactly the
issues we're trying to solve here.

> If possible we should try to resolve the complexity, not bandaid the
> problems caused by the complexity.
>
> If we can't do that then per service virtualenv (or even containers)
> provides a far more contained[1] bandage.

Per service virtualenvs are good IMO, but orthogonal to the unbounded
thing we have today, which we have largely *because* of pip not having
a resolver. (Thats driven by random things getting upgraded because of
transitive dependencies - caused by the resolver).

> Related: I personally find it completely bewildering that things are
> managed and run in such an unbounded fashion. My intuition is that
> this is the result of many/most projects being on the same release
> cycle and the belief that my master must integrate with your master. We
> should release (far) more often and my master should integrate with your
> lastest release.

Yes, I would like to see that, as a complement to the trunk<->trunk
tests. We need to know that something we're about to release won't
break folk as well as knowing that the thing we're about to release
works with the releases of other things that are already out there.

-Rob


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