Make dry-run script twice as fast

[deivid-rodriguez]

Check whether up to date after figuring latest version.

Before, on a standard Python update:

$ time bin/dry-run.rb pip LeeeeT/valtypes --cache files
To use retry middleware with Faraday v2.0+, install `faraday-retry` gem
=> reading dependency files from cache manifest: ./dry-run/LeeeeT/valtypes/cache-manifest-pip.json
=> parsing dependency files
=> updating 11 dependencies: pre-commit, isort, sort-all, black, pyproject-flake8, mypy, pyright, pytest, pytest-cov, mkdocs-material, jinja2

=== pre-commit ()
 => checking for updates 1/11
🌍 https://pypi.org/simple/pre-commit/
 => latest available version is 2.20.0
 => latest allowed version is 2.20.0
    (no update needed as it's already up-to-date)

(...)

=== jinja2 (3.1.0)
 => checking for updates 11/11
🌍 https://pypi.org/simple/jinja2/
 => latest available version is 3.1.2
🌍 https://pypi.org/simple/jinja2/
 => latest allowed version is 3.1.2
 => requirements to unlock: own
 => requirements update strategy: bump_versions
 => updating jinja2 from 3.1.0 to 3.1.2

    ± docs/requirements.txt
    ~~~
    2c2
    < Jinja2==3.1.0
    ---
    > Jinja2==3.1.2
    ~~~
🌍 Total requests made: '24'

real	1m0.863s
user	0m35.599s
sys	0m7.230s

After this change:

$ time bin/dry-run.rb pip LeeeeT/valtypes --cache files
To use retry middleware with Faraday v2.0+, install `faraday-retry` gem
=> reading dependency files from cache manifest: ./dry-run/LeeeeT/valtypes/cache-manifest-pip.json
=> parsing dependency files
=> updating 11 dependencies: pre-commit, isort, sort-all, black, pyproject-flake8, mypy, pyright, pytest, pytest-cov, mkdocs-material, jinja2

=== pre-commit ()
 => checking for updates 1/11
🌍 https://pypi.org/simple/pre-commit/
 => latest available version is 2.20.0
    (no update needed as it's already up-to-date)

(...)

=== jinja2 (3.1.0)
 => checking for updates 11/11
🌍 https://pypi.org/simple/jinja2/
 => latest available version is 3.1.2
🌍 https://pypi.org/simple/jinja2/
 => latest allowed version is 3.1.2
 => requirements to unlock: own
 => requirements update strategy: bump_versions
 => updating jinja2 from 3.1.0 to 3.1.2

    ± docs/requirements.txt
    ~~~
    2c2
    < Jinja2==3.1.0
    ---
    > Jinja2==3.1.2
    ~~~
🌍 Total requests made: '24'

real	0m27.956s
user	0m9.490s
sys	0m3.146s

So, more than 50% speed up.

And I think this also matches more closely what the real updater does.

[deivid-rodriguez]

This is @jerbob92's idea. I'm just committing what he suggested, hence the co-authorship of this PR.

[jurre]

Not sure if this is problematic, as the speedup is nice, but I think this does introduce a small functional change, for a security update, when a dependency is already up-to-date but also not vulnerable we no longer print the (no security update needed as it's not vulnerable) message anymore (or the error message in the chase the version class isn't correct).

Does this align with what we do in production? Should we also make this change there?

[deivid-rodriguez]

Nice catch @jurre, I had moved the check too early. I moved it after the message you mentioned now and we still get similar speed up. Have a look now!

Regarding production, I did have a quick look at the code and I did not see the possibility to make this same speed up. I think we're good there.

[jeffwidman]

I think this does introduce a small functional change, for a security update, when a dependency is already up-to-date but also not vulnerable we no longer print the (no security update needed as it's not vulnerable) message anymore (or the error message in the chase the version class isn't correct).

I ran into a variant of this debugging the pub security updates where the dep is up to date and vulnerable, so slightly tweaked the order here:

• Delay short-circuit in dry-run.rb if vulnerable #6258