In the publish client, we have to set the client retries to 0 as the
retry middleware is incompatible with upload bodies. This however also
sets `client.retry_policy()` to a zero-retry policy, so we need to
construct our own policy.
Fixes#12027
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
This PR moves functions for finding user- and system-level config
directories to public functions in `uv_fs::config`. This will allow them
to be used in future work without duplicating code.
This adds support for inferring dependency group conflict sets from the
directly defined conflicts in configuration. For example, if you declare
a conflict between groups `alpha` and `beta` and `dev` includes `beta`,
then we will infer a conflict between `dev` and `alpha`. We will also
handle a conflict between two groups if they transitively include groups
that conflict with each other. See #11232 for more details.
Closes#11232
## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
The way the `tool update-shell` checks if the command to export the PATH
exists or not in the RC files is a blind search, and therefore if finds
the command inside comments.
example with .zshenv
This content
```
# uv
# export PATH="/Users/cholas/.local/bin:$PATH"
```
Generates the following msg
```
error: The executable directory /Users/cholas/.local/bin is not in PATH, but the Zsh configuration files are already up-to-date
```
With this change, that content won't be considered as configured and the
following will be added
```
# uv
export PATH="/Users/cholas/.local/bin:$PATH"
```
This will make the `update-shell` more reliable
## Test Plan
I tested with and without the change with commented export in zsh in
mac. Tested running `cargo run -- tool update-shell`
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
I somehow missed running an actual integration test of the PEP 517 API
in CI and the python shim was using the old uv CLI interface still.
The tests include pip, uv and `python -m build`. They must be a in CI
job since we can't depend on the Python package in the Rust tests (we
only get the binary in `cargo test`, not the `uv_build` wheel).
## Summary
The order here is slightly off... As-is, we fetch the metadata for the
dependency, _then_ insert the URLs and indexes into the fork state -- so
the fetch doesn't take the explicit index or URL into account. This has
mostly been unobserved because we re-fetch anyway in the next request,
but if we do things in the right order (add to fork state, fetch
dependencies, insert dependencies), we can cut down on the fetches.
Closes https://github.com/astral-sh/uv/issues/12056.
Thank you for uv, it has game-changer capabilities in the field of
Python package and environment maangement!
## Summary
This is a small PR adding the option `module-name`
(`tool.uv.build-backend.module-name`) to the uv build backend (
https://github.com/astral-sh/uv/issues/8779 ).
Currently, the uv build backend will assume that the module name matches
the (dash to underdash-transformed) package name. In some packaging
scenarios this is not the case, and currently there exists no
possibility to override it, which this PR addresses.
From the main issue ( https://github.com/astral-sh/uv/issues/8779 ) I
could not tell if there is any extensive roadmap or plans how to
implement more complex scenarios, hence this PR as a suggestion for a
small feature with a big impact for certain scenarios.
I am new to Rust, I hope the borrow/reference usage is correct.
## Test Plan
So far I tested this at an example, if desired I can look into extending
the tests.
Fixes#11428
---------
Co-authored-by: konstin <konstin@mailbox.org>
This PR is in support of #12005, where we need to import
`DependencyGroups` in the `uv-pypi-types` crate without a circular
dependency on `uv-workspace`.
uv itself is a large package with many dependencies and lots of
features. To build a package using the uv build backend, you shouldn't
have to download and install the entirety of uv. For platform where we
don't provide wheels, it should be possible and fast to compile the uv
build backend. To that end, we're introducing a python package that
contains a trimmed down version of uv that only contains the build
backend, with a minimal dependency tree in rust.
The `uv_build` package is publish from CI just like uv itself. It is
part of the workspace, but has much less dependencies for its own
binary. We're using cargo deny to enforce that the network stack is not
part of the dependencies. A new build profile ensure we're getting the
minimum possible binary size for a rust binary.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
In https://github.com/astral-sh/uv/issues/11998, a user is attempting to
vendor `pydantic-core`. But when they add `pydantic-core = { path =
"src/foo/vendor/pydantic-core" } `, we're installing it as a virtual
package, since `pydantic-core/pyproject.toml` contains `package =
false`.
This PR allows users to mark dependencies as "explicitly a package" or
"explicitly not a package" (i.e., virtual), as a workaround.
Closes https://github.com/astral-sh/uv/issues/11998.
## Summary
This PR adds support for `SitePackages::satisfies` with unnamed
overrides and requirements.
The main challenge here was cases like: you have a `requirements.in`
with `git+https://github.com/pallets/flask` in it, and an
`overrides.txt` with `flask==2.0.0` in it. You _need_ to include
`flask==2.0.0`, but you can't know that without resolving the unnamed
URL requirement (since overrides only take effect when the package is
included, like constraints).
We now make the assumption that any unnamed overrides _are_ relevant,
for the purpose of the satisfies check. This is conservative, but this
whole check is an optimization anyway.
## Summary
Closes https://github.com/astral-sh/uv/issues/9151
This adds support for running .ps1, .cmd, .bat legacy scripts typically
provided by setuptools [legacy script
files](https://packaging.python.org/en/latest/guides/distributing-packages-using-setuptools/#scripts).
Note, .bat and .cmd scripts were somewhat supported previously by
[Command](https://doc.rust-lang.org/std/process/index.html#batch-file-special-handling)
when the extension was explicit but documentation says such behavior
should not be relied upon.
In addition, when no extension is provided and a legacy script exists,
it will try to infer the appropriate extension on Windows and use the
right runtime with preference for .ps1. Only powershell.exe and cmd.exe
are supported right now.
## Test Plan
Added tests. Tested with nuitka locally via uv run.
Note uvx support will be added in a follow up.
## Summary
Small omission I noticed last night. This was overly strict (so, didn't
lead to any incorrect behavior; more that we did unnecessary work in
some cases).
<!--
Thank you for contributing to uv! To help us out with reviewing, please
consider the following:
- Does this pull request include a summary of the change? (See below.)
- Does this pull request include a descriptive title?
- Does this pull request include references to any relevant issues?
-->
## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
Similar to https://github.com/astral-sh/uv/pull/11399
This adds `UV_NO_BUILD` and `UV_NO_BUILD_PACKAGE` environment variables
for non-pip commands.
## Test Plan
<!-- How was it tested? -->
Tested manually and with snapshot tests.
Fixes#11963
Signed-off-by: Alex Lowe <alex@lowe.dev>
## Summary
If we're looking at (e.g.) `python3.12`, and we have a `requires-python:
">=3.12.7, <3.13"`, then checking if the range includes `3.12` will
return `false`. Instead, we need to look at the lower- and upper-bound
major-minors of the `requires-python`.
Closes https://github.com/astral-sh/uv/issues/11825.
<!--
Thank you for contributing to uv! To help us out with reviewing, please
consider the following:
- Does this pull request include a summary of the change? (See below.)
- Does this pull request include a descriptive title?
- Does this pull request include references to any relevant issues?
-->
## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
To stay within quota, it now has just under 30 days of data, so the
filename has been updated. Both will be available for a while. See
https://github.com/hugovk/top-pypi-packages/pull/46.
## Test Plan
<!-- How was it tested? -->
```sh
curl https://hugovk.github.io/top-pypi-packages/top-pypi-packages-30-days.min.json | jq -r ❯
curl https://hugovk.github.io/top-pypi-packages/top-pypi-packages.min.json | jq -r ".rows | .
diff pypi_8k_downloads_original.txt pypi_8k_downloads_new.txt
```
We prepend the interpreter discovery in a temporary path to `sys.path`,
which we have to strip to avoid the `sys.path` value containing a
then-deleted temp dir.
I noticed that https://github.com/astral-sh/uv/pull/11936 did not run
the Docker builds, nor did #11934
We should run these when the relevant files change so there aren't
surprises at release time!
Updates the `build-binaries` workflow to include toolchain version
changes and `.cargo/config.toml` changes too.
If we see `uvx script.py`, we exit early, giving a hint to use `uv run
script.py` if the script exists. If it does not exist, we suggest
running `uv run` with a normalized package name.
This PR includes a snapshot test for each of these scenarios.
An alternative approach would be to wait until we encounter an error,
and then add the hint. But if there happens to be a malicious package
called `script-py`, this would be run unintentionally (a point raised by
@zanieb).
Closes#10784
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
<!--
Thank you for contributing to uv! To help us out with reviewing, please
consider the following:
- Does this pull request include a summary of the change? (See below.)
- Does this pull request include a descriptive title?
- Does this pull request include references to any relevant issues?
-->
## Summary
Fix error message suggesting `--user` instead of `--username`:
```
> uv publish --publish-url ... ... --password $(cat ~/.token)
Publishing 1 file to ...
error: Attempted to publish with a password, but no username. Either provide a username with `--user` (`UV_PUBLISH_USERNAME`), or use `--token` (`UV_PUBLISH_TOKEN`) instead of a password.
> uv publish --publish-url ... ... --user lewis --password $(cat ~/.token)
error: unexpected argument '--user' found
tip: a similar argument exists: '--username'
Usage: uv publish <FILES|--index <INDEX>|--username <USERNAME>|--password <PASSWORD>|--token <TOKEN>|--trusted-publishing <TRUSTED_PUBLISHING>|--keyring-provider <KEYRING_PROVIDER>|--publish-url <PUBLISH_URL>|--check-url <CHECK_URL>|--skip-existing>
For more information, try '--help'.
```
## Test Plan
I have not tested manually, I'm hoping this isn't necessary and there
will be sufficient CI coverage.
<!--
Thank you for contributing to uv! To help us out with reviewing, please
consider the following:
- Does this pull request include a summary of the change? (See below.)
- Does this pull request include a descriptive title?
- Does this pull request include references to any relevant issues?
-->
## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
<!-- How was it tested? -->
