build(deps): avoid version conflicts

[qued]

Addresses #631.

• Uses constraints to keep dependency versions more consistent.
• Moves all dependencies to .in files which are then ingested by setup.py.
• Adds script to check consistency of all extras.
• Adds consistency check to CI.

I should note that while it shouldn't be possible to cause a conflict between base.txt and any of the extras (because base.txt constrains all the extras) it is possible to get a conflict between two of the extras files. There are ways of trying to avoid that (like constraining each file by all the files that have already been processed before it in the order given in the make pip-compile target) but the ones I could think of seemed a little overwrought, and come with problems of their own. If a conflict arises, it should be flagged by CI or locally with make check-deps. When/if that happens, you can resolve the conflict by adding appropriate global constraints in requirements/constraints.txt.

Also note that if fileA.in is constrained by fileB.txt, then fileB.in should be compiled before fileA.in in the make pip-compile target. Otherwise fileA.in will be compiled with the old version of fileB.txt which can cause conflicts or keep dependencies from being updated properly.

Testing:

• Verify make check-deps says deps are consistent.
• Change line 59 of requirements/ingest-s3.txt to:

urllib3==1.27.1

• Verify make check-deps produces an error.

[cragwolfe]

Flagging @ryannikolaidis in case he is aware of any potential downstream issues with the urllib<2 pin. But, really great to see the dep issues sorted out and a way of preventing the mismatches in the future. Passing CI with Dockerfile is also promising 🤞 .

[ryannikolaidis]

Flagging @ryannikolaidis in case he is aware of any potential downstream issues with the urllib<2 pin. But, really great to see the dep issues sorted out and a way of preventing the mismatches in the future. Passing CI with Dockerfile is also promising 🤞 .

Thanks! Nope, I don't think we had anything explicitly forcing our hand. iirc the main push to urllib3 was because the latest for a bunch of our dependencies were requiring urllib3>2. As long as we're okay with those not getting bumps, then I don't think there are any other immediate concerns.

Thanks for this @qued! 🙏

[cragwolfe]

LGTM!