Open Stack

On 4/17/20 1:40 PM, Radosław Piliszek wrote:
> Yeah. That is all true.
>
> I just wanted to let you know that lower-constraints may break more
> often when run outside of CI.
>
> That said, what should lower-constraints really include?
> I understand [1] that it should just explicitly ask for specific
> versions of packages in requirements.txt
> However, per what Sean just told me [2], it is seemingly not enough.
> All in all, it passed CI checks successfully. :-)
>
> [1] https://docs.openstack.org/project-team-guide/dependency-management.html#update-processes
> [2] https://review.opendev.org/720754
>
> -yoctozepto

This had to be explained to me a few times before I got it, so don't
feel bad. ;)

The lower-constraints file really does need to include everything, not
just the project's direct dependencies. If it only contains what is
listed in requirements.txt, then there is the possibility that one of
the indirect dependencies that does not strictly enforce its own
required version will end up pulling in a newer version than what is
expected.

The goal of lower constraints testing is to have a static set of all
requirements that are known and validated to work. If we only restrict
the 1st level dependencies, then without changing anything, that known
set that was passing tests could suddenly stop working.

We actually had a good discussion of this on IRC today, so it might be
helpful to read that for a little more context:

http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.2020-04-17.log.html#t2020-04-17T15:33:38

I think ultimately the goal when this was added was to be able to
communicate downstream an acceptable range of compatible packages that
could be installed together and expect to work.

We could probably be more aggressive about raising those minimums to
keep picking up newer things. But unless we can get a static(ish)
snapshot of the whole dependency graph like this, even that would like
break often. Or not accurately test what we think we are testing.