Zanie Blue

@charliermarsh Could you open an issue that describes what change would be needed for this issue? (even if it's brief)

Yeah we want to solve that problem, but it's not trivial.

Can you please share more about your use-case?

Are ya'll definitely testing the same uv version? The image could be cached if you're just using that example repository.

I also cannot reproduce (similarly, on an M3 with Docker Desktop) ``` ❯ docker build -t uv-example . [+] Building 3.0s (10/10) FINISHED docker:desktop-linux => [internal] load build definition from...

I'm also using the default settings, which afaict includes VirtioFS, Rosetta, and the Virtualization framework.

I think if the `.python-version` conflicts with a script's Python requirement, we should prefer the script's definition. This is consistent with projects — which won't use a `.python-version` file from...

Yeah, that's the suggestion. I think we'd at least want to log that we were ignoring it though. > This is consistent with projects — which won't use a `.python-version`...

Hm yeah so at best we would be guessing. There's relevant discussion about tracking the metadata at https://github.com/pypa/packaging-problems/issues/215 maybe we should just track this?

`uv tree` can use the lockfile metadata to identify which extra a package was installed from, whereas the `uv pip` interface (and virtual environments more generally) do not have this...