-
Notifications
You must be signed in to change notification settings - Fork 809
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
uv pip compile
chokes on requirements files with explicit file:...
requirements
#3934
Comments
uv pip install with a file: URI has regressed on slightly newer uv. See astral-sh/uv#3934. This reverts commit 1d03249.
We can strip it, but why include the egg fragment at all? |
That's the standard (to pip, it's not in any PEP AFAIK) way to indicate what the name of your package is. In which cases at this point in 2024 is that needed rather than falling back to parsing it out of pyproject.toml once building the wheel starts I don't know, but as far as I recall it's always been encouraged to include. |
https://pip.pypa.io/en/stable/cli/pip_install/#working-out-the-name-and-version is the pip docs though they don't elaborate any further really. |
I'll fix this case but note: https://pip.pypa.io/en/stable/topics/vcs-support/#url-fragments
|
That section seems to only be referring to VCS URLs, though I'm sure you're right to point it out as it seems unlikely that it should be any more needed for archive or path URLs -- but given pypa/pip#1289 still being open and that more broadly as an end user it's been way easier over the years to find an incantation that works and never change rather than keep track of what's what, I'm quite glad that you're interested in the fix nonetheless. |
My read of that thread and the Python Discuss thread is that it's only necessary at all for editable VCS URLs though I don't fully understand why it's necessary even in that case, and that the goal is to deprecate it entirely. I only mention this because I don't want others to read this issue and think that Regardless, fixed in #3940, since it's a legitimate bug on our end! |
## Summary This will help prevent bugs like #3934 by unifying the implementations for editables and non-editable unnamed requirements. Specifically, both of these now go through the same parsing paths and use the same struct representations (with the exception that the editable flag is flipped in the first case): ``` -e ./foo/bar ./foo/bar ``` We also now support PEP 508 in editable URLs. It turns out this is just a limitation in pip, so it's correct to support it. For example, this now works: ``` -e black[d] @ file://${PROJECT_ROOT}/scripts/packages/black_editable ``` Closes #3941. Closes #3942.
Given a trivial (i.e. empty) package
foo
, and arequirements.in
containing:(i.e. simply saying "install this package"),
uv pip compile requirements.in
crashes with:pip-compile
of course still works:though
uv
is unable to install what it produces, even thoughpip
can:This is on macOS with:
where it seems some parsing is being done but the fragment hasn't been stripped.
(#3180 is related, as it's there again that this manifests for me, I once again cannot output something which both
uv
andpip
are happy with, being on an olderuv
when first running the compile managed to get a compiled requirements file which as aboveuv
itself could then not install)The text was updated successfully, but these errors were encountered: