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.


Sean Dague

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to