Support URL and path dependencies without a package name #313
Comments
charliermarsh
added
the
enhancement
|
\cc @konstin - do you know if these are spec-compliant? Or legacy? |
|
They are iirc not part of PEP 621 and PEP 508, but they are supported in many places ( |
|
Sadly, adds a lot of complexity. |
|
Oh this is the syntax I use every time I install a package from I'm not sure if we really need to support it in a requirements file? Unless it's common in the wild. Generally it seems reasonable to have a nice error suggesting inclusion of the package name. |
|
If we support it at all, then it’s not too hard to support it in a requirements file too. |
|
Although, I guess it lets us skip supporting it in the parser. Anyway, we probably do need to support this long-term if it’s allowed in pyproject.toml. |
|
But yeah we should support them :) |
charliermarsh
changed the title
|
@konstin - Do you think we should make |
|
We should add a |
|
I'll give this another try. |
|
Would you mind waiting until #587 is merged? Editables will profit from this, but doing it now would clash badly. |
|
Will do! |
`pip` supports installing packages without names (e.g., `git+https://github.com/pallets/flask.git`), but it doesn't adhere to the PEP grammar, and we don't yet support it (and may never) (#313). This PR adds a dedicated error path for such cases, to ensure that we can give meaningful feedback to the user: ``` error: Couldn't parse requirement in requirements.in position 0 to 18 Caused by: URL requirement is missing a package name; expected: `package_name @ https://google.com` https://google.com ^^^^^^^^^^^^^^^^^^ ``` Closes #650.
|
It seems like this is also an issue for installing a local whl file? % uv pip install ./streamlit-1.31.1-py2.py3-none-any.whl
error: Failed to parse `./streamlit-1.31.1-py2.py3-none-any.whl`
Caused by: Expected package name starting with an alphanumeric character, found '.'
./streamlit-1.31.1-py2.py3-none-any.whl
^
% uv pip install "streamlit @ ./streamlit-1.31.1-py2.py3-none-any.whl"
Resolved 40 packages in 680ms
Downloaded 40 packages in 1.74s
Installed 40 packages in 97ms
...BTW |
|
Yup, all the same issue! Although we can probably support local wheels "trivially" since the file name is required to be encoded in the wheel. |
|
This is probably the biggest blocker to experimenting with uv in Meltano since dependencies of the type |
|
Loving Will supporting this also allow the very basic |
|
Yup! |
|
Publicly committing to this one. |
|
I've a similar issue with a requirements.txt file that contains a package installed as:
at the moment Will this syntax be supported? There is an alternative way to install a specific package in requirements in current folder from a github repo? Thanks |
|
You can do |
|
Yes, but in that case it'll be installed under python path and not under current folder.. also with standard pip the behavior is different |
|
We don't support editable installs for Git and URL dependencies. I'd suggest just cloning the repo and installing it as a file-based editable install ( |
|
Okay, this is now in review. |
## Summary First piece of #313. In order to support unnamed requirements, we need to be able to parse them in `requirements-txt`, which in turn means that we need to introduce a new type that's distinct from `pep508::Requirement`, given that these _aren't_ PEP 508-compatible requirements. Part of: #313.
## Summary This PR enables `uv pip install` to accept unnamed requirements, as long as the requirement ends with the wheel or source distribution archive name. For example: `cargo run pip install ~/Downloads/anyio-4.3.0.tar.gz`. In subsequent PRs, I'll expand the scope of supported archives and patterns. Part of: #313.
## Summary For example: `cargo run pip install .` The strategy taken here is to attempt to extract the package name from the distribution without executing the PEP 517 build steps. We could choose to do that in the future if this proves lacking, but it adds complexity. Part of: #313.
## Summary This PR ensures that if a package is already satisfied by the current environment, we don't bother resolving the named requirement. Part of: #313. ## Test Plan - `cargo run pip install ./scripts/editable-installs/black_editable` - `cargo run pip install black --verbose`
## Summary In `pip uninstall`, we shouldn't need to resolve unnamed requirements, since we already index packages in `site-packages` by their URL. This also changes `uninstall` to ignore editables, which matches pip's behavior. Part of: #313. ## Test Plan Run `cargo run pip install ./scripts/editable-installs/black_editable`, followed by each of the following: - `cargo run pip uninstall ./scripts/editable-installs/black_editable` - `cargo run pip uninstall black` - `cargo run pip uninstall ./scripts/editable-installs/black_editable black`
## Summary Enables, e.g., `uv pip install git+https://github.com/pallets/flask.git`. Part of: #313.
|
These have all merged. Will be supported in the next release. |
|
Thank you so much for making this, makes a world of a difference ! |
Apparently this works with pip?
As opposed to:
We could decide not to support these. I don't know if they're spec-compliant.
The text was updated successfully, but these errors were encountered: