On 16 April 2015 at 00:51, Jeremy Stanley <fu...@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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ 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