On 22 January 2015 at 02:48, Chris Dent <chd...@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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev