Open Stack

On 16 April 2015 at 00:51, Jeremy Stanley <fungi at yuggoth.org> wrote:
> On 2015-04-15 11:06:20 +0200 (+0200), Thierry Carrez wrote:
>> And the doc is indeed pretty clear. I assumed "requirements.txt" would
>> describe... well... requirements. But like Robert said they are meant to
>> describe specific deployments (should really be have been named
>> deployment.txt, or at least dependencies.txt).
>
> It may also just be that we overloaded the meaning of that filename
> convention without realizing. Rewind to a couple years ago we had
> essentially the same file but it was called tools/pip-requires
> instead. I wonder if continuing to have it called something else
> would have been less confusing to the Python developer community,
> but the damage is done now.
>
> Ultimately we just want a way to maintain a list of application or
> library dependencies in such a way that when someone uses pip
> install they get a fully-working installation without having to know
> to run additional commands, and for us to be able to keep that list
> in a machine-parsable file which isn't also source code fed to a
> turing-complete interpreter.

I think this is too narrow a description of our needs. See the
audience list I proposed to Thierry :).

The heart of the conflict is this:
'pip install git+..../nova.git' cannot itself have Known Good
dependencies. Because multiple repos prohibit developers putting exact
versions in install_requires, and chicken-and-egg with knowing its
good from CI if we generate the file from CI.

install_requires can however have Known Bad exclusions. Which is the
intended use. And we can (and should) have a Known Good somewhere.

We could generate that in advance as
https://review.openstack.org/#/c/161047/ proposes - we'll know that
any commit that got through CI worked with a precise list fed into it,
but we can't trivially reconstruct what list was used. (Log scraping
is not 'trivial' - it requires deep knowledge of our infra and
processes).

Or we can generate it as a by product of CI, same issued about getting
hold of the data as in my prior paragraph, but we'll have the ability
to use floating versions as our inputs - so this would be suitable and
relevant for master as well as stable.

We can of course do both:
 - precapped gate lists for stable branches, and captured output to a
common place for consumption by deployers/testers
 - looser gate lists for master branches, captured in the same way to
the same place as stable branches, for deployers/testsers

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud