Open Stack

Robert Collins wrote:
> On 13 April 2015 at 13:09, Robert Collins <robertc at robertcollins.net> wrote:
>> On 13 April 2015 at 12:53, Monty Taylor <mordred at inaugust.com> 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)