Minimum-Supported-Version (MSV) strategy for dependency version

[T-256]

[dependencies]
mydep = { msv = "1.0.0" }

Why not version = "^1.0.0"?

1. mydep release version 2 and 3, but our crate still supports version 1 and both of new majors.
2. Maintaining costs.

What should we do when mydep released incompatible version?

For example, assume it released incompatible "1.2.3", Then we should release a patch version for our package with considering one of these scenarios:

• If they didn't still fix incompatibility:

  [dependencies]
  mydep = { msv = "1.0.0", conflict = ">=1.2.3" }

• They fixed incompatibility in "1.5.0":

  [dependencies]
  mydep = { msv = "1.0.0", conflict = ">=1.2.3, <1.5" }

We should also keep these conflicts until msv exceed each of them.

Notes

• msv and conflict could have better naming.
• msv doesn't accept version specifiers (e.g. ">=")
• conflict only supports comma-saparated of >= <= > <.
• It is more simple, readable than befor in my POV.

This idea actually inspired from here.

I didn't find the best equality of { msv = "1.0.0", conflict = ">=1.2.3, <1.5" } in version specifiers. WDYT?

[dimbleby]

when building the wheel, poetry has to express your new syntax in the standard way in the wheel metadats - that's how other projects get to find out what dependencies your project supports and allows.

what is the translation from your new syntax into the standard syntax? why not just write standard version constraints in the first place?

this isn't going to happen

[T-256]

this isn't going to happen

I agree, just opened to discuss the idea.

when building the wheel, poetry has to express your new syntax in the standard way in the wheel metadats - that's how other projects get to find out what dependencies your project supports and allows.

Assume, there is an imaginary pypkg build that also supports this MSV-with-Conflict support. Since msv key not accepting specifiers, pypkg would use 1.0.0 -: >=1.2.3, <1.5 syntax in metadata (syntax is discussable).
OR as WHEEL improvement proposal:

Requires-Dist: my_dep (1.0.0 -: >=1.2.3, <1.5)

what is the translation from your new syntax into the standard syntax? why not just write standard version constraints in the first place?

The issue is that there is not equality of that example in current version specifiers (at least I didn't find).

I also opened discussion for Rust's cargo but since Rust accept different versions of a dependency at same time and it applies stricter SEMVER in crates creation time, MSV would not fix any problem for Rust ecosystem.

[T-256]

I will create a discussion in python site.

[dimbleby]

if what you actually want to propose is a change to the python packaging standards then for sure https://discuss.python.org/c/packaging/14 is a better place than here.

I don't honestly expect you'll have much joy there either: but it's anyway the right place to try

[T-256]

Created a topic: https://discuss.python.org/t/minimum-supported-version-msv-strategy-for-dependency-version