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.
It'd be interesting to see what a distribution (canonical, redhat...)
would think about this movement. I know yahoo! has been looking into it
for similar reasons (but we are more flexibly then I think a packager
such as canonical/redhat/debian/... would/culd be). With a move to
venv's that seems like it would just offload the work to find the set of
dependencies that work together (in a single-install) to packagers instead.
Is that ok/desired at this point?
-Josh
-Sean
__________________________________________________________________________
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
