On Sun, Apr 12, 2015 at 6:09 PM, Robert Collins <robe...@robertcollins.net> wrote:
> On 13 April 2015 at 12:53, Monty Taylor <mord...@inaugust.com> wrote: > > > What we have in the gate is the thing that produces the artifacts that > > someone installing using the pip tool would get. Shipping anything with > > those artifacts other that a direct communication of what we tested is > > just mean to our end users. > > Actually its not. > > What we test is point in time. At 2:45 UTC on Monday installing this > git ref of nova worked. > > Noone can reconstruct that today. > > I entirely agree with the sentiment you're expressing, but we're not > delivering that sentiment today. > > We need to balance the inability to atomically update things - which > forces a degree of freedom on install_requires - with being able to > give someone the same install that we tested. > > That is the fundamental tension that we're not handling well, nor have > I seen a proposal to tackle it so far. > > I'll have to spend some time noodling on this, but one of the clear > constraints is that install_requires cannot both be: > - flexible enough to permit us to upgrade requirements across many > git based packages [because we could do coordinated releases of sdists > to approximate atomic bulk changes] > - tight enough enough to give the next person trying to run that ref > of the package the same things we installed in CI. > > -> I think we need something other than install_requires > > ... > > I disagree that anything is broken for us that is not caused by our > > inability to remember that distro packaging concerns are not the same as > > our concerns, and that the mechanism already exists for distro pacakgers > > to do what they want. Furthermore, it is caused by an insistence that we > > need to keep versions "open" for some ephemeral reason such as "upstream > > might release a bug fix" Since we all know that "if it's not tested, > > it's broken" - any changes to upstream software should be considered > > broken until proven otherwise. History over the last 5 years has shown > > this to be accurate more than the other thing. > > This seems like a strong argument for really being able to reconstruct > what was in CI. > > > If we pin the stable branches with hard pins of direct and indirect > > dependencies, we can have our stable branch artifacts be installable. > > Thats awesome. IF there is a bugfix release or a security update to a > > dependent library - someone can propose it. Otherwise, the stable > > release should not be moving. > > Can we do that in stable branches? We've still got the problem of > bumping dependencies across multiple packages. > We cannot do this today with 'pip install -r requirements.txt' but we can with 'pip install -r --no-deps requirements.txt' if requirements includes all transitive dependencies. And then we have to figure out transitive dependencies for all projects etc. What do you mean bumping dependencies across mulitple packages? > > -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 >
__________________________________________________________________________ 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
