Since when does Dependabot bump the lower version of a package?

[jenstroeger]

Hello, I’m somewhat puzzled that Dependabot has changed behavior and now bumps both lower and upper version range… unasked?

See for example an older PR jenstroeger/python-package-template#1185 and then the most recent PR jenstroeger/python-package-template#1222 for the same package which bumps both sides of the range? The latter is not a correct bump because it turns the valid package range into an exact pin which is not what I’m interested in.

First glance at the docs didn’t reveal an option to disable this behavior.

Thanks!

[kaminagakur4]

Nothing changed in Dependabot's rules. What changed is which rule you fall under, and it's decided by a PyPI lookup on your project's own name.

For pip, Dependabot picks the strategy like this (python/lib/dependabot/python/update_checker.rb):

library? ? RequirementsUpdateStrategy::WidenRanges : RequirementsUpdateStrategy::BumpVersions

WidenRanges moves only the upper bound, which is what your #1185 did. BumpVersions moves both, which is what #1222 did and why the range collapsed to a pin.

And library? isn't about your repo layout. It's check_pypi_for_library_match, which takes the name from your pyproject.toml, fetches https://pypi.org/pypi/<name>/json/, and returns true only if PyPI's info.summary is byte-identical to your local description.

Your pyproject.toml declares name = "package". So the lookup goes to https://pypi.org/pypi/package/json/, which is a real package owned by someone else. It returns 200 with:

summary: "package is a package to package your package"

That obviously doesn't match your description, so library? is false, so you get BumpVersions. Had the name not resolved on PyPI at all you'd have fallen through to the has_library_metadata branch and been treated as a library.

The fix is to stop letting it guess. In .github/dependabot.yml:

updates:
  - package-ecosystem: "pip"
    directory: "/"
    versioning-strategy: widen

That's checked before the heuristic runs, so the PyPI comparison never happens.

One thing I can't pin down: which side flipped between May and July. Either that PyPI summary changed, or your description did, or the detection did. The versioning-strategy line makes it moot either way, and it also stops this from silently flipping back if someone edits either string.

[jenstroeger]

Thank you for this detailed response, I changed the code accordingly in PR jenstroeger/python-package-template#1283 as you suggested 🙏🏻

[kaminagakur4]

No worries at all, you're good. The one line in #1283 is the right lever, so you should be set. I enjoy digging into these, so it was no trouble. Good luck with the template.

[jenstroeger]

Huh, Dependabot failed (link):

The property '#/updates/0/versioning-strategy' value "widen" did not match one of the following values: lockfile-only, auto, increase, increase-if-necessary

even though widen is documented here and should apply to the pip ecosystem. Because issue #6630 🤦🏻‍♂️

[kaminagakur4]

Sorry, that one is on me. The strategy exists in the code, but the service has never accepted it in the config file, which is exactly what #6630 has been tracking since February 2023, still open. The docs page listing widen under pip is the half that is wrong.

Use increase-if-necessary instead. It is in the allowed list the validator printed at you, and for pyproject it does what you actually asked for:

versioning-strategy: increase-if-necessary

The reason it works is in python/lib/dependabot/python/update_checker/requirements_updater.rb. increase calls update_pyproject_version_core(req, bump_lower_bound: true), and that path bumps every clause, including your >=, which is how the range collapsed. increase-if-necessary goes through update_pyproject_version_if_needed, which passes bump_lower_bound: false and lands in update_requirements_range, where each clause already satisfied by the new version is kept verbatim:

next r.to_s if r.satisfied_by?(latest_resolvable_version)

A >= lower bound is always satisfied by a newer version, so it survives untouched, and only < and <= move.

Concretely, on the requirement from #1222: hypothesis >=6.21.0,<6.152.10 with 6.156.1 available, increase-if-necessary gives you >=6.21.0,<6.156.2. Same upper bound that PR proposed, lower bound left alone.

It is also quieter than widen would have been. skip_pyproject_update? drops the update entirely while the new version still satisfies your range and there is no lockfile, so you only get a PR when the ceiling is actually in the way.

Worth knowing that this is decided before the library heuristic runs, so it does not matter what PyPI says about package any more, and it will not flip back if either description string is edited later.