Reconsider rangeStrategy=auto behavior for Poetry

[rarkins]

Tell us more.

Today rangeStrategy=auto usually defaults to update-lockfile for managers, which makes a lot of sense, i.e.

• Do not change or bump the constraints in the package file, such as ^1.0.0
• Instead, change the version in the lock file

The problem with Poetry and some others managers is that they don't support a "precise" way of changing a locked version. Instead we can only say "update foo in the lock file" and it might be updated higher than we intended if a newer compatible version exists, or lower if for some reason poetry cannot fully resolve that version in compatibility with other versions.

We probably have a choice of:

• rangeStrategy=replace, which means Poetry repos will stop getting in-range updates. e.g. if the package file says ^1.0.0 and locked version is 1.1.0 then there won't be a PR when 1.2.0 comes out
• rangeStrategy=pin, which will mean ^1.0.0 is first changed/pinned to 1.1.0 in the pyproject.toml and after that the repo will get precise updates to new versions like 1.2.0 whenever available

We usually don't default to pinning because that seems too "opinionated" and in the case of libraries, wrong to narrow ranges unnecessarily. But for Poetry it's not utilized for building libraries - only applications - so the latter is not a concern.

In summary:

• Defaulting rangeStrategy=auto to update-lockfile results in a use which can be unreliable
• Changing to replace will mean less PRs and potentially people thinking it's "broken"
• Changing to pin will mean same number of PRs and reliability but users may think it's too opinionated

[vladimir-avinkin]

We usually don't default to pinning because that seems too "opinionated" and in the case of libraries, wrong to narrow ranges unnecessarily.

I think it's okay, sure if you can - stick to lockfile-update in managers where it works properly. But IMO sticking to pin is better than getting potentially inconsistent MRs, not many people see those warnings in renovate manager docs when onboarding a project with renovate.

But for Poetry it's not utilized for building libraries - only applications - so the latter is not a concern.

Not sure how true it is, we're using poetry for libraries too :) Maybe we're wrong here. Either way, a default won't satisfy everyone, so i think defaulting to pin(arguably a more common use case) is okay. For specific situations such as libraries, users can already opt-in to use other strategies,

[rarkins]

You're right, it can be used for libraries too. I corrected that above

[riconnon]

I think whatever is done here the Python version constraint in the poetry manager likely needs special behaviour.