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#upd... [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.2... 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.