Open bes-alielzein opened 6 days ago
That's surprising to me -- I don't think we have any control over the error message there, it comes directly from the build backend.
Oh wait, these are both uv. I thought the second trace was pip install
. That's even more surprising to me then hah.
Is it the same Python version in both cases?
Is it the same Python version in both cases?
I would think so? When we got the logs for this, we run uv pip install
immediatly after uv sync
, so it should be using the same venv. The global Python install is also 3.12.3
Also of note, running standard pip
directly in the venv created by the failed uv sync
command worked, (probably that the path is just short enough w/o uv's cache being used)
djangorestframework-camel-case
is probably only relevant here in that it's one of our longest-named dependency, just enough to trigger the issue.
Wild guess (I don't know too much about uv's internals), looks like the sync command may accidentally suppress the "path too long" error, then failing because the egg-info failed to be created.
Also for any future reader, the solution is: https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation#registry-setting-to-enable-long-paths
This issue is simply about showing a more helpful error message when using uv sync
When long paths are not enabled on Windows,
uv sync
fails with an unclear error. However, when using pip, the error message is revealing the actual issue (path is too long).Reference to the config: https://github.com/BesLogic/releaf-canopeum/blob/bcb64747ba6a28f5c5c3c6072ee2bd7ce1445ca9/canopeum_backend/pyproject.toml
UV version: 0.4.10
uv sync --locked --extra dev
The error is in french and translates to: "The system cannot find the path specified".
However, when running the following command:
uv pip install -e .[dev]
The error message is different. The error message translates to: "The filename or extension is too long".