Enforce correctness of self-dependencies

[charliermarsh]

Summary

As far as I can tell, this was added in #319, but it seems incorrect to ignore these.

Closes #9693.

[zanieb]

Hm I'm a little worried about the implications of this. Will it break people with dynamic versions?

[charliermarsh]

Why would it break people with dynamic versions?

[charliermarsh]

(This only affects packages that declare dependencies on themselves, which is itself almost always a mistake.)

[zanieb]

I'm imagining you have a self-dependency with a version constraint that.. works in production but fails locally due some weird dynamic development version scheme? Perhaps I'm overthinking it. Dynamic versions stood out to me as a case where there are weird local versions, but I don't think that's the only case where there could be a mismatch.

More broadly, what happens with a self-dependency in production i.e. published to PyPI?

[charliermarsh]

More broadly, what happens with a self-dependency in production i.e. published to PyPI?

Can you expand on this? If you install the package from PyPI, and it declares a dependency on itself, they will just resolve to the same package. The same is true if you clone the package and install it locally. Both would work fine.

The case we would fail is: you declare a self-dependency, but at a version that is incompatible with the current package version. I think that should fail! Check out the linked issue where we silently succeed with a broken resolution.

(I don’t know that there’s even a real, valid use-case for a self-dependency.)

[zanieb]

I did read the linked issue :) just trying to understand the problem more broadly since it turns something that's currently allowed into a firm error.

The case we would fail is: you declare a self-dependency, but at a version that is incompatible with the current package version. I think that should fail!

I guess the clarifying question is: would this fail at publish or install time to / from PyPI? (entirely separately from uv)

[charliermarsh]

By “publish time”, do you mean, if you ran uv lock locally prior to publishing?

[zanieb]

I mean.. if you weren't using uv at all, i.e., some lower-level tools like python -m build and twine.

[charliermarsh]

Hmm, none of those tools have to resolve dependencies though. There’s no dependency validation. They just have to construct the metadata. They don’t have to solve the graph.

[zanieb]

Yeah so then when you install with pip later what would happen? Perhaps there would be a failure then?

[charliermarsh]

Yeah it would fail then. Though I think that’s the same as if, e.g., the package declared dependencies on both flask==3.0.0 and flask==2.0.0? It would fail on install, but not on publish.

[zanieb]

Okay, thanks for going through it with me. I'm not quite sure where this change could cause problems 👍

(I don’t know that there’s even a real, valid use-case for a self-dependency.)

I guess it'd let you declare a default extra that.. you can't turn off? 😬

[charliermarsh]

Gah, need to fix this error message.

[zanieb]

I thought we already had a hint for self dependencies 🤔

[zanieb]

I was thinking of #7505 (which may help guide the messaging here?)

[charliermarsh]

I added hints!

[charliermarsh]

We could choose to omit these? This is a useless self-dependency. I retained them but we could omit them when converting from PubGrub resolution to our own graph.

[charliermarsh]

Kind of weak.

[zanieb]

I'd include the specifier and the version maybe?

Suggested change

	╰─▶ Because your project depends on itself at an incompatible version, we can conclude that your project's requirements are unsatisfiable.
	╰─▶ Because your project depends on itself (project==0.2.0) at an incompatible version (currently 0.1.0), we can conclude that your project's requirements are unsatisfiable.

[charliermarsh]

I actually don't think I can get the version here right now :/

[charliermarsh]

Kind of weak.

[notatallshaw-gts]

Just want to check this doesn't break the real use case of using extras to depend on other extras of your own project? e.g.

[project]
name = "spam-eggs"
version = "2020.0.0"
requires-python = ">=3.8"

[project.optional-dependencies]
tests = ["pytest"]
dev = ["pdb", "memray"]
all = [
  "spam-eggs[tests]",
  "spam-eggs[dev]",
]

[charliermarsh]

No, that remains totally fine.

[charliermarsh]

It would error if you did:

[project]
name = "spam-eggs"
version = "2020.0.0"
requires-python = ">=3.8"

[project.optional-dependencies]
tests = ["pytest"]
all = [
  # Incompatible version!
  "spam-eggs[tests]==2021.0.0",
]