If you install the project with `--no-dev` and then use `uv run` you get a cache-miss

[juliancoffee]

To be honest, I solved the issue I had even before posting it, but I thought I want to post it somewhere anyway.

So if we install our project dependencies (and then the project itself) with uv sync --frozen ... --no-dev, we can only cache production dependencies (which should've been obvious, yes), but any uv command, such as uv run will check uv.lock again and install all of them (including dev dependencies), which in my case took about additional 7 seconds.

I was building a Django project and was frustrated to no end, and I thought that these 7 seconds came from the Django setup code. But then I checked uv issue guide, and tweaked the RUST_LOG variable to see what's going on, maybe it is uv, after all, why would I see Installed N packages in my logs?

2024-12-17 20:33:32 DEBUG Identified uncached distribution: django-debug-toolbar==4.4.6
2024-12-17 20:33:32 DEBUG Identified uncached distribution: django-stubs==5.1.1
2024-12-17 20:33:32 DEBUG Identified uncached distribution: mypy==1.13.0
2024-12-17 20:33:32 DEBUG Identified uncached distribution: ruff==0.8.0
2024-12-17 20:33:32 DEBUG Requirement already installed: django==5.1.3
...
2024-12-17 20:33:32 DEBUG Requirement already installed: asgiref==3.8.1
2024-12-17 20:33:32 DEBUG Identified uncached distribution: django-stubs-ext==5.1.1
2024-12-17 20:33:32 DEBUG Identified uncached distribution: types-pyyaml==6.0.12.20240917
2024-12-17 20:33:32 DEBUG Requirement already installed: typing-extensions==4.12.2
2024-12-17 20:33:32 DEBUG Identified uncached distribution: mypy-extensions==1.0.0
2024-12-17 20:33:32 DEBUG Requirement already installed: packaging==24.2
2024-12-17 20:33:32 DEBUG Requirement already installed: psycopg-binary==3.2.3
2024-12-17 20:33:32 DEBUG Requirement already installed: brotli==1.1.0
...
2024-12-17 20:33:32 DEBUG No cache entry for: https://files.pythonhosted.org/packages/2f/33/2036a472eedfbe49240dffea965242b3f444de4ea4fbeceb82ccea33a2ce/django_debug_toolbar-4.4.6-py3-none-any.whl
2024-12-17 20:33:32 DEBUG No cache entry for: https://files.pythonhosted.org/packages/9e/2c/c1d81d680997d24b0542aa336f0a65bd7835e5224b7670f33a7d617da379/types_PyYAML-6.0.12.20240917-py3-none-any.whl
2024-12-17 20:33:32 DEBUG No cache entry for: https://files.pythonhosted.org/packages/6a/ed/f79ae5ad993bdf900d61892d2a9fc0145441a507a7579890fb8e21e4a7bc/django_stubs_ext-5.1.1-py3-none-any.whl
2024-12-17 20:33:32 DEBUG No cache entry for: https://files.pythonhosted.org/packages/2a/e2/5d3f6ada4297caebe1a2add3b126fe800c96f56dbe5d1988a2cbe0b267aa/mypy_extensions-1.0.0-py3-none-any.whl
...
2024-12-17 20:33:39 Installed 7 packages in 49ms

(And as if gods laugh at me, I have 7 INSTALLED_APPS in Django config, so that was the root of my confusion)

So yeah, this problem isn't reproducible if you "give up" on uv and sort of activate the environment with ENV PATH="/app/.venv/bin:$PATH" and then keep calling python manage.py ... or fastapi dev as in the example, or if you run uv run --no-dev, but it's still a silent landmine that can bite you.

And tbh, I can't think of a proper "solution" to this "problem" if it even counts as a problem, and if it is, whether it's something that can be improved here with documentation or if people just need to read existing docs more thoroughly, because it is probably explained somewhere 😅

[zanieb]

Ah yeah sorry. Not sure what to do about this. We could add a UV_NO_DEV environment variable?

[abhiaagarwal]

This has caused issues bc my containers run in environments without internet. I've been getting around with this with uv run --no-sync foo which seems to be working fine.

Per the docs, it seems like setting UV_NO_SYNC should also solve the issue? I didn't realize the environment variable exists. It should be added to the example.

[juliancoffee]

Yeah, I guess if we already have UV_NO_SYNC, we could add UV_NO_DEV.
However, I think adding UV_NO_DEV would require an issue on the main repo for more visibility? 😅

But yeah, we could at least document this in the example.

[abhiaagarwal]

Arguably, this should be generalized because --no-dev is an alias for --no-group dev. Maybe something like UV_EXCLUDE_GROUPS that is comma-separated?

I often build GPU/CPU enabled containers and am forced to have two separate dockerfiles — I could consolidate them by having this set by an ARG, such that my cpu container could build with the --build-arg="UV_EXCLUDE_GROUPS=dev,gpu" and the gpu container being --build-arg="UV_EXCLUDE_GROUPS=dev".

[juliancoffee]

Yeah, this might be even better, because UV_NO_DEV is somewhat obscure, IMO.
UV_EXCLUDE_GROUPS states the purpose of the variable more clearly.

[yiphei]

ran into this problem today. Would have really appreciated if this case were covered by https://docs.astral.sh/uv/guides/integration/docker/