Robert Collins wrote: > On 13 April 2015 at 13:09, Robert Collins <[email protected]> wrote: >> On 13 April 2015 at 12:53, Monty Taylor <[email protected]> wrote: >> >>> What we have in the gate is the thing that produces the artifacts that >>> someone installing using the pip tool would get. Shipping anything with >>> those artifacts other that a direct communication of what we tested is >>> just mean to our end users. >> >> Actually its not. >> >> What we test is point in time. At 2:45 UTC on Monday installing this >> git ref of nova worked. >> >> Noone can reconstruct that today. >> >> I entirely agree with the sentiment you're expressing, but we're not >> delivering that sentiment today. > > This observation led to yet more IRC discussion and eventually > https://etherpad.openstack.org/p/stable-omg-deps > > In short, the proposal is that we: > - stop trying to use install_requires to reproduce exactly what > works, and instead use it to communicate known constraints (> X, Y is > broken etc). > - use a requirements.txt file we create *during* CI to capture > exactly what worked, and also capture the dpkg and rpm versions of > packages that were present when it worked, and so on. So we'll build a > git tree where its history is an audit trail of exactly what worked > for everything that passed CI, formatted to make it really really easy > for other people to consume.
I totally agree that we need to stop trying to provide two different sets of dependency information (known good deps, known bad deps) using the same dataset. If I understand you correctly, today we provide a requirements.txt and generate an install_requires from it, and in the new world order we would provide a install_requires with "known-bad" info in it and generate a "known-good" requirements.txt (during CI) from it. Questions: How would global-requirements evolve in that picture ? Would we have some "global-install-requires" thing to replace it ? Distro packagers today rely on requirements.txt (and global -requirements) to determine what version of libraries they need to package. Would they just rely on install_requires instead ? Where is that information provided ? setup.cfg ? How does this proposal affect stable branches ? In order to keep the breakage there under control, we now have stable branches for all the OpenStack libraries and cap accordingly[1]. We planned to cap all other libraries to "the version that was there when the stable branch was cut". Where would we do those cappings in the new world order ? In install_requires ? Or should we not do that anymore ? [1] http://specs.openstack.org/openstack/openstack-specs/specs/library-stable-branches.html -- Thierry Carrez (ttx) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
