-
Notifications
You must be signed in to change notification settings - Fork 524
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
compiles requirements files with explicit file:...
requirements into something which pip
can't install
#3180
Comments
uv pip compile
compiles requirements files with explicit file:...#egg
requirements into something which pip
can't installuv pip compile
compiles requirements files with explicit file:...
requirements into something which pip
can't install
Oh, I misspoke when I said I am still chasing pypa/pip#4208 and some other tickets to remind myself what's expected to work, but I filed this at least to see if someone who already knows can tell me :) EDIT: pypa/pip#8035 and jazzband/pip-tools#1650 seem relevant. |
I ran into the same issue, and it makes the transition from pip to uv harder. I have a |
Yeah pip does not support relative paths in requirements.txt. We support reading them in requirements.txt (but not pyproject.toml, since that has to follow PEP 508). So if you leverage that feature, it will knowingly compile to something pip can't install. You can instead use pip and uv both support relative paths for |
(Thanks for the response!)
It does though doesn't it? Or do you mean to say "officially"? (I.e. it's hard to tell whether what works works intentionally). Specifically, both of these work fine:
and
Where I've told both pip and uv to install a relative path to some package. What doesn't work, or what I was trying to communicate in the issue, was basically if you have that in a requirements file, |
Oh sorry, so you're saying it does support unnamed relative requirements? |
Correct! |
That's weird. Maybe we should add support over there? It seems like a bad thing to not track the name. |
That seems like the correct approach, but the |
I think we should consider always outputting without the name when it's a relative path. |
When relative paths are in the inputs and outputs, not everyone agrees on which path they ought to be relative to. My own opinion is that any relative path should be relative to the file it appears in. But that can be trouble when e.g. installing with pip from another working directory. |
perhaps a flag to include/exclude the name for relative paths? my workaround right now is to remove the prefix after running compile, and re-add it when running it again. |
## Summary This PR falls back to writing an unnamed requirement if it appears to be a relative URL. pip is way more flexible when providing an unnamed requirement than when providing a PEP 508 requirement. For example, _only_ this works: ``` black @ file:///Users/crmarsh/workspace/uv/scripts/packages/black_editable ``` Any other form will fail. Meanwhile, _all_ of these work: ``` file:///Users/crmarsh/workspace/uv/scripts/packages/black_editable scripts/packages/black_editable ./scripts/packages/black_editable file:./scripts/packages/black_editable file:scripts/packages/black_editable ``` Closes #3180.
I believe this seems to have regressed (as of 0.2.2, but I see also in 0.2.5) -- but now it's |
Given a
requirements.in
file containing eitherfile:.#egg=foo
orfile:/Users/Julian/Desktop/foo/#egg=foo
,uv pip compile
emits a requirement which looks like a combination of the input and a PEP508 requirement, specificallyfoo @ file:/Users/Julian/Desktop/foo/#egg=foo
-- but neitherpip
norpip-compile
can deal with such a requirement, they both blow up when seeing it.E.g.:
Changing the input to instead bethe history of relative paths and requirements files in pip is ... "interesting" I know, so I don't recall why I continue to usefoo @ thepath
obviously works correctly --file:.
everywhere in my packages, I'll have to see what breaks if I switch, but it seems like ifuv pip compile
is going to muck with the input anyhow that it likely should go further and changefile:.#egg=foo
to just.
and emitfoo @ .
?This is on macOS with:
The text was updated successfully, but these errors were encountered: