analyze_deps doesn't consider version semantics

[chlowell]

Given the version string azure-core>=1.0.0b1,<2.0.0 in both a library's setup.py and the repo's shared_requirements.txt, analyze_deps will consider the library's version not to match the frozen version, evidently due to the sorted order of the specifiers:

'azure-core<2.0.0,>=1.0.0b1' which does not match the frozen requirement 'azure-core>=1.0.0b1,<2.0.0'

See e.g. this build.

According to its documentation, specifier order isn't meaningful for setuptools, i.e. <2.0.0,>=1.0.0b1 and >=1.0.0b1,<2.0.0 are equivalent.

[bsiegel]

The analyzer definitely attempts to do this, I will have to look at the specific build here to see why it’s failing.

[chlowell]

This is still happening, though it seems for a different reason. E.g. from internal build 20190805.4:

The following libraries declare requirement 'azure-core<2.0.0,>=1.0.0b2' which does not match the frozen requirement 'azure-core<2.0.0,>=1.0.0b1':

• azure-identity

I expect >=1.0.0b2 to satisfy a shared requirement for >=1.0.0b1, and I can imagine a future in which some of our packages depend on different versions of a common dependency such that they can't all share the same literal requirement string.

[bsiegel]

I expect >=1.0.0b2 to satisfy a shared requirement for >=1.0.0b1, and I can imagine a future in which some of our packages depend on different versions of a common dependency such that they can't all share the same literal requirement string.

The analyzer is working as expected in this case. The goal is to enforce that the exact same specifier is used for each library that depends on a certain dependency, not to ensure that the ranges are merely compatible. In situations as you describe, we add an override for a specific library and dependency+version, but we also want to make sure to file an issue to remove the override since adding an override is intended to be temporary.

I will file an issue to track adding an override to the analyze_deps.py script.

[bsiegel]

Filed #6708