Add CI tests for dependency conflicts

[schmmd]

Occasionally AllenNLP has dependency conflicts, see #1824 and #2195. We don't catch these conflicts ourselves because pip is rather flexible about how it resolves dependencies, but when we publish releases some of our users run into them (either because they use poetry or run conda forge).

Ideally we would run a stricter check ourselves which would allow us to address these issues as they happen--rather than hearing about them after a release.

[schmmd]

@sodre @phireski do either of you have a suggestion about a tool we should use to identify dependency conflicts earlier?

[sodre]

@schmmd, I asked in the conda-forge gitter channel. I'll report back once I get something.

[epwalsh]

FWIW I currently use pipdeptree for this purpose in some of my projects as part of my CI pipeline.

[schmmd]

I did some brief searching today but didn't come up with a clear option for how to test for conflicts in our dependencies.

[epwalsh]

@schmmd did you happen to look at pipdeptree? This is the exact script I run in CI to check for conflicts:

#!/bin/sh
set -e
pipdeptree --warn fail 1>/dev/null

[schmmd]

@epwalsh thanks for the reminder. I'll take a look. I assumed (for some reason) that it draws a tree rather than checks for conflicts.

[schmmd]

#2195 claimed that v0.7.2 had a dependency conflict that we should have caught. Unfortunately pipdeptree --warn fail does not catch this.

[matt-gardner]

@schmmd, any updates here or ideas on how to proceed with this issue?

[schmmd]

I have no idea what to do. Unassigning myself.

[matt-gardner]

Adding this to the 1.0 milestone, so we can revisit this issue once we've pruned our dependencies after moving things to sub-repos. That might just solve the problem.

[DeNeutoy]

Marking this as fixed by adding dependabot to our repo, e.g #3623 . This doesn't directly fix this issue, as it's still possible to have conflicting version pins, but this should become more unlikely now the versions we pin to get updated automatically. Also, we didn't have a good alternative solution, because it's a hard problem in general.

Feel free to re-open if we think of a better way to do something about this.

[schmmd]

@DeNeutoy thanks for closing that out. It's a reasonable action given where we are (which is much better than before).