Is uv sync intended for developing libraries?

[ryanhiebert]

I'm authoring a python library package (Aldjemy), and I'm running into a problem that I think I've seen before (with Poetry) that makes me think that I'm probably not using uv correctly, but I'm not really sure what is and is not intended.

When I do uv sync --upgrade, it always installs Django 4.2. If I attempt to force it to use Django 5.1.3, I get the following message:

  × No solution found when resolving dependencies:
  ╰─▶ Because the requested Python version (>=3.9) does not satisfy Python>=3.10 and django==5.1.3 depends on Python>=3.10, we can conclude that django==5.1.3
      cannot be used.
      And because your project depends on django==5.1.3, we can conclude that your project's requirements are unsatisfiable.

      hint: The `requires-python` value (>=3.9) includes Python versions that are not supported by your dependencies (e.g., django==5.1.3 only supports
      >=3.10). Consider using a more restrictive `requires-python` value (like >=3.10).

It's clear to me that this is treating the Python dependency differently from other dependencies. Instead of ensuring that my package requires 3.9+, which I'd expect to cause problems attempting to install in a lower version of Python but not a higher version, it's making sure that all my dependencies, transitively add no further restriction to my acceptable Python versions.

Right at this moment I'm not imaginative enough to figure out why someone would want this behavior, but I'm pretty sure it's not the behavior I should be wanting. Is there a better way to do what I'm trying to do? Is uv sync the wrong tool? (I like that it will quickly create and manage the venv for me). Is this the wrong way to specify minimum versions for libraries?

[FishAlchemist]

I think it's because UV is looking for a compatible version. If you want to use Django >= 5.0, the minimum required Python version would be Python 3.10.
Moreover, the project series' features, such as uv lock and uv sync, aim to generate universal or cross-platform lockfiles. As a result, based on your dependency requirements, it cannot find a Django version compatible with Python 3.9.
https://docs.astral.sh/uv/concepts/projects

[FishAlchemist]

Therefore, if you have a dependency on Python 3.9, you can only choose to rely on versions of Django below 5.0, or have Python 3.9 and Python 3.10 rely on different versions of Django.

Examples of dependencies on different versions:

requires-python = ">=3.9"
dependencies = [
  "SQLAlchemy>=1.4,<2",
  "Django>=5.0 ; python_version >= '3.10'",
  "Django<5.0 ; python_version < '3.10'"
]

Edit:
Are you looking for UV to automatically generate support for using Django 4.2.16 with Python 3.9, and Django 5.1.3 with Python 3.10 or higher?
Currently, UV's lock file, without Environment Markers, will search for the single compatible version that meets the current requirements. Therefore, if you don't use PEP 508 Environment Markers, it won't be able to meet your needs.

[ryanhiebert]

Your example would have encoded too much restriction. However, with that hint I was able to find this solution that tells the resolver that it'll need to look for multiple versions of Django depending on the Python version, without adding addition restrictions for my library's consumers.

requires-python = ">=3.9"
dependencies = [
  "SQLAlchemy>=1.4",
  "Django>=4.2 ; python_version >= '3.9'",
  "Django>=5.0 ; python_version >= '3.10'",
]

Are you looking for UV to automatically generate support for using Django 4.2.16 with Python 3.9, and Django 5.1.3 with Python 3.10 or higher?

Yes, this would be great.

Currently, UV's lock file, without Environment Markers, will search for the single compatible version

Thank you for explaining that. I think I can work with this limitation of the resolver, although I'd be very happy to see this limitation lifted.

I found these other issues and pull requests that seem related to this, for anyone else that stumbles across this issue and wants to see what happens: #8492, #7190, #8686