Gracefully handle cargo version conflicts

[xlgmokha]

Why is this needed?

This addresses a failure that occurs when two direct cargo dependencies have
conflicting constraints against a common indirect dependency.

What does this do?

This change pushes down a line that raises an error before the check
for a version constraint conflict has occurred.

Fixes https://github.com/github/dependabot-updates/issues/1104

Before:

[dependabot-core-dev] ~/dependabot-core $ ./bin/dry-run.rb cargo djc/template-benchmarks-rs --cache=files --dep=ructe
=> reading dependency files from cache manifest: ./dry-run/djc/template-benchmarks-rs/cache-manifest-cargo.json
=> parsing dependency files
=> updating 1 dependencies: ructe

=== ructe (0b8acfe5eea15713bc56c156f974fa05967d0353)
 => checking for updates 1/1
 => latest available version is acbe090356c7964123eba5d25f3437f31944cfc3
 => handled error whilst updating ructe: dependency_file_not_resolvable {:message=>"Updating git repository `https://github.com/kaj/ructe`\n    Updating crates.io index\nerror: failed to select a version for `nom`.\n    ... required by package `ructe v0.13.1-PRE (https://github.com/kaj/ructe#acbe0903)`\n    ... which is depended on by `template-benchmarks-rs v0.1.0 (/home/dependabot/dependabot-core/dependabot_tmp_dir)`\nversions that meet the requirements `^6.1.0` are: 6.1.2, 6.1.1, 6.1.0\n\nall possible versions conflict with previously selected packages.\n\n  previously selected package `nom v6.0.1`\n    ... which is depended on by `askama_shared v0.11.1 (https://github.com/djc/askama?branch=main#bc2e92e7)`\n    ... which is depended on by `askama v0.10.5 (https://github.com/djc/askama?branch=main#bc2e92e7)`\n    ... which is depended on by `template-benchmarks-rs v0.1.0 (/home/dependabot/dependabot-core/dependabot_tmp_dir)`\n\nfailed to select a version for `nom` which could resolve this conflict"}

After:

[dependabot-core-dev] ~/dependabot-core $ ./bin/dry-run.rb cargo djc/template-benchmarks-rs --cache=files --dep=ructe
=> reading dependency files from cache manifest: ./dry-run/djc/template-benchmarks-rs/cache-manifest-cargo.json
=> parsing dependency files
=> updating 1 dependencies: ructe

=== ructe (0b8acfe5eea15713bc56c156f974fa05967d0353)
 => checking for updates 1/1
 => latest available version is acbe090356c7964123eba5d25f3437f31944cfc3
 => latest allowed version is 0b8acfe5eea15713bc56c156f974fa05967d0353
 => requirements to unlock: update_not_possible
 => requirements update strategy: bump_versions
    (no update possible 🙅‍♀️)

Type of change

• Bug fix (non-breaking change which fixes an issue)

[xlgmokha]

Are there additional steps to take to test this against test projects in the dsp-testing org?

[feelepxyz]

Wondering, could we cut this down to just ructe and askma which seem to have the conflicting deps? Had a go at testing this locally and the first time the test ran it took over 2 mins to run so might be due to the large poject

[xlgmokha]

Ah, yes. I remember you mentioned that we should whittle this down to just the important bits. I'll try to reduce this and the .lock file to just the relevant bits.

[feelepxyz]

Nice one, you might be able to just edit the Cargo.toml and run cargo generate-lockfile

[feelepxyz]

This is probably the right thing considering all existing specs pass but can't say I understand what all possible versions conflict actually means 😅

[xlgmokha]

I was hoping that a failing test would guide me. I quick dive into the history lead me to a PR where the rubocop rule for line length changed from 80 to 120. I didn't go deeper than that. I'll do a deeper dive and see what source of additional context that I can discover.

[feelepxyz]

Thanks for putting this together and sorry for the slow review, got swamped by the bundler work.

I think this change makes sense and existing tests pass so 👍 on the change. I think the way we'll gain confidence in cargo is by making more changes and responding to issues that crop up.

Just had a comment about slimming down the test fixtures if possible, wouldn't spend ages on it but if it would work by just removing all deps except ructe and askma seems like it could speed up tests a fair bit?

[feelepxyz]

Are there additional steps to take to test this against test projects in the dsp-testing org?

I would usually trust tests and dry-runs for these kinds of changes. Testing it end to end in staging would add hours to the rollout right now 😬

You could test the repo in question with: bin/dry-run.rb cargo "repo/name" --cache=files if it's public and see how the updater would handle it.

[xlgmokha]

Do you mind taking another look @feelepxyz?

[feelepxyz]

Nice one 🙌 LGTM