On Fri, Feb 20, 2015 at 7:27 AM, Doug Hellmann <[email protected]> wrote:
> > > On Fri, Feb 20, 2015, at 06:06 AM, Sean Dague wrote: > > On 02/20/2015 12:26 AM, Adam Gandelman wrote: > > > Its more than just the naming. In the original proposal, > > > requirements.txt is the compiled list of all pinned deps (direct and > > > transitive), while requirements.in <http://requirements.in> reflects > > > what people will actually use. Whatever is in requirements.txt affects > > > the egg's requires.txt. Instead, we can keep requirements.txt unchanged > > > and have it still be the canonical list of dependencies, while > > > reqiurements.out/requirements.gate/requirements.whatever is an upstream > > > utility we produce and use to keep things sane on our slaves. > > > > > > Maybe all we need is: > > > > > > * update the existing post-merge job on the requirements repo to > produce > > > a requirements.txt (as it does now) as well the compiled version. > > > > > > * modify devstack in some way with a toggle to have it process > > > dependencies from the compiled version when necessary > > > > > > I'm not sure how the second bit jives with the existing devstack > > > installation code, specifically with the libraries from git-or-master > > > but we can probably add something to warm the system with dependencies > > > from the compiled version prior to calling pip/setup.py/etc > > > <http://setup.py/etc> > > > > It sounds like you are suggesting we take the tool we use to ensure that > > all of OpenStack is installable together in a unified way, and change > > it's installation so that it doesn't do that any more. > > > > Which I'm fine with. > > > > But if we are doing that we should just whole hog give up on the idea > > that OpenStack can be run all together in a single environment, and just > > double down on the devstack venv work instead. > > I don't disagree with your conclusion, but that's not how I read what he > proposed. :-) > > Sean was reading between the lines here. We are doing all this extra work to make sure OpenStack can be run together in a single environment, but it seems like more and more people are moving away from deploying with that model anyway. Moving to this model would require a little more then just installing everything in separate venvs. We would need to make sure we don't cap oslo libraries etc. in order to prevent conflicts inside a single service. And we would still need a story around what to do with stable branches, how do we make sure new libraries don't break stable branches -- which in turn can break master via grenade and other jobs. > Joe wanted requirements.txt to be the pinned requirements computed from > the list of all global requirements that work together. Pinning to a > single version works in our gate, but makes installing everything else > together *outside* of the gate harder because if the projects don't all > sync all requirements changes pretty much at the same time they won't be > compatible. > > Adam suggested leaving requirements.txt alone and creating a different > list of pinned requirements that is *only* used in our gate. That way we > still get the pinning for our gate, and the values are computed from the > requirements used in the projects but they aren't propagated back out to > the projects in a way that breaks their PyPI or distro packages. > > Another benefit of Adam's proposal is that we would only need to keep > the list of pins in the global requirements repository, so we would have > fewer tooling changes to make. > > Doug > > > > > -Sean > > > > -- > > Sean Dague > > http://dague.net > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > > [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
