Open Stack

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. :-)

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:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev