Skip to content

Conversation

@zanieb
Copy link
Member

@zanieb zanieb commented Feb 18, 2025

Closes #7804

Includes a few small minor changes to the messaging, but the primary change is that in, e.g., uvx foo, if the foo package does not provide the foo executable we will no longer execute an arbitrary foo executable if present on the PATH. This prevents confusing and surprising behavior, such as the user reported where they did uv tool install foobar (which provides foo) then uvx foo (which does not provide foo) later falls back to the executable provided by foobar since it's on the PATH. We don't enforce this for --from, so things like uvx --from foo bash -c "..." are still totally valid. We also still allow uvx foo where the foo executable is provided by a dependency of foo instead of foo itself.

Most of the diff here is consolidating the logic of the hint_on_not_found and warn_executable_not_provided_by_package utilities.

The following executables are provided by `black`:
- black
- blackd
Consider using `uv tool run --from black <EXECUTABLE_NAME>` instead.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The user is already using --from here, I don't think we should hint it again.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's intended to be shown for like

❯ uvx fastapi-cli
Installed 21 packages in 46ms
The executable `fastapi-cli` was not found.
warning: An executable named `fastapi-cli` is not provided by package `fastapi-cli`.
The following executables are provided by `fastapi-cli`:
- fastapi
Consider using `uvx --from fastapi-cli <EXECUTABLE_NAME>` instead.

success: false
exit_code: 1
----- stdout -----
The executable `fastapi-cli` was not found.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We no longer attempt to execute this / succeed if it's on the PATH. Instead, we exit early.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Arguably, this is breaking — but I think this is a bug.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think as a user I wouldn't expect uvx to execute something just because it's on the PATH

The following executables are available:
- change_wheel_version
Use `uv tool run --from change-wheel-version change_wheel_version` instead.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sort of tempted to just run the command when it matches the module-normalized package name :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does seem designed to confound the user. But are there cases where this could be a coincidence?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't really think of one, no.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tracking in #12976

@zanieb zanieb changed the title Improve executable checks in uvx Require the command in uvx <name> to be available in the Python environment Feb 18, 2025
@zanieb zanieb marked this pull request as ready for review February 18, 2025 21:30
}

impl std::fmt::Display for ExecutableProviderPackages<'_> {
fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
Copy link
Contributor

@jtfmumm jtfmumm Apr 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems surprising that Display doesn't display the representation of the type but warning and error information. Should this be a separate dedicated function or method?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure, the type only exists for the purpose of rendering these messages. Previously, it was a function that called warn_user and println directly but here I want the caller to be able to make that decision and I think Display is the easiest way to do that. I think I'd just end up needing into introduce a separate type, like ExecutableProviderPackagesDisplay that implements Display? Or I'd need to implement like fn message(&self)-> String and construct a string instead of using Formatter?

Copy link
Contributor

@jtfmumm jtfmumm Apr 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was confused when I encountered writeln!(printer.stderr(), "{providers}")?; above (before seeing this code). I didn't understand why you would just log the providers without context. It seems pretty non-standard to have Display perform conditional logic and log warnings.

I'd recommend something like providers.log_warnings() (or something more descriptive) to accomplish what you're doing here. You could pass in printer.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perform conditional logic and log warnings.

To be clear, it only logs one warning (which we could omit, but I don't think it really hurts — it's a case that should never happen). The rest of it is just writing to the formatter.

I can't use a function that takes a printer because I want to be able to use it in warn_user_once.

I see this as the same thing as implementing Display on an error type, which we frequently include more context on. Would it be clearer if it was named like ExecutableProviderHints instead?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that would be clearer

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense, thanks!

@jtfmumm
Copy link
Contributor

jtfmumm commented Apr 18, 2025

Left a few comments but generally looks good.

@zanieb zanieb force-pushed the zb/tool-run-check branch from 5a8ca3d to 02e5fb4 Compare April 18, 2025 21:37
@zanieb zanieb added the breaking A breaking change label Apr 18, 2025
@zanieb zanieb changed the base branch from main to release/070 April 18, 2025 21:38
@zanieb zanieb force-pushed the zb/tool-run-check branch from 02e5fb4 to 5456abd Compare April 18, 2025 21:49
@zanieb zanieb merged commit a75e449 into release/070 Apr 18, 2025
85 checks passed
@zanieb zanieb deleted the zb/tool-run-check branch April 18, 2025 21:57
Gankra pushed a commit that referenced this pull request Apr 24, 2025
…ironment (#11603)

Closes #7804

Includes a few small minor changes to the messaging, but the primary
change is that in, e.g., `uvx foo`, if the `foo` package does not
provide the `foo` executable we will no longer execute an arbitrary
`foo` executable if present on the `PATH`. This prevents confusing and
surprising behavior, such as the user reported where they did `uv tool
install foobar` (which provides `foo`) then `uvx foo` (which does not
provide `foo`) later falls back to the executable provided by `foobar`
since it's on the `PATH`. We don't enforce this for `--from`, so things
like `uvx --from foo bash -c "..."` are still totally valid. We also
still allow `uvx foo` where the `foo` executable is provided by a
_dependency_ of `foo` instead of `foo` itself.

Most of the diff here is consolidating the logic of the
`hint_on_not_found` and `warn_executable_not_provided_by_package `
utilities.
zanieb added a commit that referenced this pull request Apr 29, 2025
…ironment (#11603)

Closes #7804

Includes a few small minor changes to the messaging, but the primary
change is that in, e.g., `uvx foo`, if the `foo` package does not
provide the `foo` executable we will no longer execute an arbitrary
`foo` executable if present on the `PATH`. This prevents confusing and
surprising behavior, such as the user reported where they did `uv tool
install foobar` (which provides `foo`) then `uvx foo` (which does not
provide `foo`) later falls back to the executable provided by `foobar`
since it's on the `PATH`. We don't enforce this for `--from`, so things
like `uvx --from foo bash -c "..."` are still totally valid. We also
still allow `uvx foo` where the `foo` executable is provided by a
_dependency_ of `foo` instead of `foo` itself.

Most of the diff here is consolidating the logic of the
`hint_on_not_found` and `warn_executable_not_provided_by_package `
utilities.
zanieb added a commit that referenced this pull request Apr 29, 2025
…ironment (#11603)

Closes #7804

Includes a few small minor changes to the messaging, but the primary
change is that in, e.g., `uvx foo`, if the `foo` package does not
provide the `foo` executable we will no longer execute an arbitrary
`foo` executable if present on the `PATH`. This prevents confusing and
surprising behavior, such as the user reported where they did `uv tool
install foobar` (which provides `foo`) then `uvx foo` (which does not
provide `foo`) later falls back to the executable provided by `foobar`
since it's on the `PATH`. We don't enforce this for `--from`, so things
like `uvx --from foo bash -c "..."` are still totally valid. We also
still allow `uvx foo` where the `foo` executable is provided by a
_dependency_ of `foo` instead of `foo` itself.

Most of the diff here is consolidating the logic of the
`hint_on_not_found` and `warn_executable_not_provided_by_package `
utilities.
tmeijn pushed a commit to tmeijn/dotfiles that referenced this pull request May 10, 2025
This MR contains the following updates:

| Package | Update | Change |
|---|---|---|
| [astral-sh/uv](https://github.com/astral-sh/uv) | minor | `0.6.16` -> `0.7.3` |

MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot).

**Proposed changes to behavior should be submitted there as MRs.**

---

### Release Notes

<details>
<summary>astral-sh/uv (astral-sh/uv)</summary>

### [`v0.7.3`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#073)

[Compare Source](astral-sh/uv@0.7.2...0.7.3)

##### Enhancements

-   Add `--dry-run` support to `uv self update` ([#&#8203;9829](astral-sh/uv#9829))
-   Add `--show-with` to `uv tool list` to list packages included by `--with` ([#&#8203;13264](astral-sh/uv#13264))
-   De-duplicate fetched index URLs ([#&#8203;13205](astral-sh/uv#13205))
-   Support more zip compression formats: bzip2, lzma, xz, zstd ([#&#8203;13285](astral-sh/uv#13285))
-   Add support for downloading GraalPy ([#&#8203;13172](astral-sh/uv#13172))
-   Improve error message when a virtual environment Python symlink is broken ([#&#8203;12168](astral-sh/uv#12168))
-   Use `fs_err` for paths in symlinking errors ([#&#8203;13303](astral-sh/uv#13303))
-   Minify and embed managed Python JSON at compile time ([#&#8203;12967](astral-sh/uv#12967))

##### Preview features

-   Build backend: Make preview default and add configuration docs ([#&#8203;12804](astral-sh/uv#12804))
-   Build backend: Allow escaping in globs ([#&#8203;13313](astral-sh/uv#13313))
-   Build backend: Make builds reproducible across operating systems ([#&#8203;13171](astral-sh/uv#13171))

##### Configuration

-   Add `python-downloads-json-url` option for `uv.toml` to configure custom Python installations via JSON URL ([#&#8203;12974](astral-sh/uv#12974))

##### Bug fixes

-   Check nested IO errors for retries ([#&#8203;13260](astral-sh/uv#13260))
-   Accept `musllinux_1_0` as a valid platform tag ([#&#8203;13289](astral-sh/uv#13289))
-   Fix discovery of pre-release managed Python versions in range requests ([#&#8203;13330](astral-sh/uv#13330))
-   Respect locked script preferences in `uv run --with` ([#&#8203;13283](astral-sh/uv#13283))
-   Retry streaming downloads on broken pipe errors ([#&#8203;13281](astral-sh/uv#13281))
-   Treat already-installed base environment packages as preferences in `uv run --with` ([#&#8203;13284](astral-sh/uv#13284))
-   Avoid enumerating sources in errors for path Python requests ([#&#8203;13335](astral-sh/uv#13335))
-   Avoid re-creating virtual environment with `--no-sync` ([#&#8203;13287](astral-sh/uv#13287))

##### Documentation

-   Remove outdated description of index strategy ([#&#8203;13326](astral-sh/uv#13326))
-   Update "Viewing the version" docs ([#&#8203;13241](astral-sh/uv#13241))

### [`v0.7.2`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#072)

[Compare Source](astral-sh/uv@0.7.1...0.7.2)

##### Enhancements

-   Improve trace log for retryable errors ([#&#8203;13228](astral-sh/uv#13228))
-   Use "error" instead of "warning" for self-update message ([#&#8203;13229](astral-sh/uv#13229))
-   Error when `uv version` is used with project-specific flags but no project is found ([#&#8203;13203](astral-sh/uv#13203))

##### Bug fixes

-   Fix incorrect virtual environment invalidation for pre-release Python versions ([#&#8203;13234](astral-sh/uv#13234))
-   Fix patching of `clang` in managed Python sysconfig ([#&#8203;13237](astral-sh/uv#13237))
-   Respect `--project` in `uv version` ([#&#8203;13230](astral-sh/uv#13230))

### [`v0.7.1`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#071)

[Compare Source](astral-sh/uv@0.7.0...0.7.1)

##### Enhancement

-   Add support for BLAKE2b-256 ([#&#8203;13204](astral-sh/uv#13204))

##### Bugfix

-   Revert fix handling of authentication when encountering redirects ([#&#8203;13215](astral-sh/uv#13215))

### [`v0.7.0`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#070)

[Compare Source](astral-sh/uv@0.6.17...0.7.0)

This release contains various changes that improve correctness and user experience, but could break some workflows; many changes have been marked as breaking out of an abundance of caution. We expect most users to be able to upgrade without making changes.

##### Breaking changes

-   **Update `uv version` to display and update project versions ([#&#8203;12349](astral-sh/uv#12349

    Previously, `uv version` displayed uv's version. Now, `uv version` will display or update the project's version. This interface was [heavily requested](astral-sh/uv#6298) and, after much consideration, we decided that transitioning the top-level command was the best option.

    Here's a brief example:

    ```console
    $ uv init example
    Initialized project `example` at `./example`
    $ cd example
    $ uv version
    example 0.1.0
    $ uv version --bump major
    example 0.1.0 => 1.0.0
    $ uv version --short
    1.0.0
    ```

    If used outside of a project, uv will fallback to showing its own version still:

    ```console
    $ uv version
    warning: failed to read project: No `pyproject.toml` found in current directory or any parent directory
      running `uv self version` for compatibility with old `uv version` command.
      this fallback will be removed soon, pass `--preview` to make this an error.

    uv 0.7.0 (4433f41c9 2025-04-29)
    ```

    As described in the warning, `--preview` can be used to error instead:

    ```console
    $ uv version --preview
    error: No `pyproject.toml` found in current directory or any parent directory
    ```

    The previous functionality of `uv version` was moved to `uv self version`.
-   **Avoid fallback to subsequent indexes on authentication failure ([#&#8203;12805](astral-sh/uv#12805

    When using the `first-index` strategy (the default), uv will stop searching indexes for a package once it is found on a single index. Previously, uv considered a package as "missing" from an index during authentication failures, such as an HTTP 401 or HTTP 403 (normally, missing packages are represented by an HTTP 404). This behavior was motivated by unusual responses from some package indexes, but reduces the safety of uv's index strategy when authentication fails. Now, uv will consider an authentication failure as a stop-point when searching for a package across indexes. The `index.ignore-error-codes` option can be used to recover the existing behavior, e.g.:

    ```toml
    [[tool.uv.index]]
    name = "pytorch"
    url = "https://download.pytorch.org/whl/cpu"
    ignore-error-codes = [401, 403]
    ```

    Since PyTorch's indexes always return a HTTP 403 for missing packages, uv special-cases indexes on the `pytorch.org` domain to ignore that error code by default.
-   **Require the command in `uvx <name>` to be available in the Python environment ([#&#8203;11603](astral-sh/uv#11603

    Previously, `uvx` would attempt to execute a command even if it was not provided by a Python package. For example, if we presume `foo` is an empty Python package which provides no command, `uvx foo` would invoke the `foo` command on the `PATH` (if present). Now, uv will error early if the `foo` executable is not provided by the requested Python package. This check is not enforced when `--from` is used, so patterns like `uvx --from foo bash -c "..."` are still valid. uv also still allows `uvx foo` where the `foo` executable is provided by a dependency of `foo` instead of `foo` itself, as this is fairly common for packages which depend on a dedicated package for their command-line interface.
-   **Use index URL instead of package URL for keyring credential lookups ([#&#8203;12651](astral-sh/uv#12651

    When determining credentials for querying a package URL, uv previously sent the full URL to the `keyring` command. However, some keyring plugins expect to receive the *index URL* (which is usually a parent of the package URL). Now, uv requests credentials for the index URL instead. This behavior matches `pip`.
-   **Remove `--version` from subcommands ([#&#8203;13108](astral-sh/uv#13108

    Previously, uv allowed the `--version` flag on arbitrary subcommands, e.g., `uv run --version`. However, the `--version` flag is useful for other operations since uv is a package manager. Consequently, we've removed the `--version` flag from subcommands — it is only available as `uv --version`.
-   **Omit Python 3.7 downloads from managed versions ([#&#8203;13022](astral-sh/uv#13022

    Python 3.7 is EOL and not formally supported by uv; however, Python 3.7 was previously available for download on a subset of platforms.
-   **Reject non-PEP 751 TOML files in install, compile, and export commands ([#&#8203;13120](astral-sh/uv#13120), [#&#8203;13119](astral-sh/uv#13119

    Previously, uv treated arbitrary `.toml` files passed to commands (e.g., `uv pip install -r foo.toml` or `uv pip compile -o foo.toml`) as `requirements.txt`-formatted files. Now, uv will error instead. If using PEP 751 lockfiles, use the standardized format for custom names instead, e.g., `pylock.foo.toml`.
-   **Ignore arbitrary Python requests in version files ([#&#8203;12909](astral-sh/uv#12909

    uv allows arbitrary strings to be used for Python version requests, in which they are treated as an executable name to search for in the `PATH`. However, using this form of request in `.python-version` files is non-standard and conflicts with `pyenv-virtualenv` which writes environment names to `.python-version` files. In this release, uv will now ignore requests that are arbitrary strings when found in `.python-version` files.
-   **Error on unknown dependency object specifiers ([12811](astral-sh/uv#12811

    The `[dependency-groups]` entries can include "object specifiers", e.g. `set-phasers-to = ...` in:

    ```toml
    [dependency-groups]
    foo = ["pyparsing"]
    bar = [{set-phasers-to = "stun"}]
    ```

    However, the only current spec-compliant object specifier is `include-group`. Previously, uv would ignore unknown object specifiers. Now, uv will error.
-   **Make `--frozen` and `--no-sources` conflicting options ([#&#8203;12671](astral-sh/uv#12671

    Using `--no-sources` always requires a new resolution and `--frozen` will always fail when used with it. Now, this conflict is encoded in the CLI options for clarity.
-   **Treat empty `UV_PYTHON_INSTALL_DIR` and `UV_TOOL_DIR` as unset ([#&#8203;12907](astral-sh/uv#12907), [#&#8203;12905](astral-sh/uv#12905

    Previously, these variables were treated as set to the current working directory when set to an empty string. Now, uv will ignore these variables when empty. This matches uv's behavior for other environment variables which configure directories.

##### Enhancements

-   Disallow mixing requirements across PyTorch indexes ([#&#8203;13179](astral-sh/uv#13179))
-   Add optional managed Python archive download cache ([#&#8203;12175](astral-sh/uv#12175))
-   Add `poetry-core` as a `uv init` build backend option ([#&#8203;12781](astral-sh/uv#12781))
-   Show tag hints when failing to find a compatible wheel in `pylock.toml` ([#&#8203;13136](astral-sh/uv#13136))
-   Report Python versions in `pyvenv.cfg` version mismatch ([#&#8203;13027](astral-sh/uv#13027))

##### Bug fixes

-   Avoid erroring on omitted wheel-only packages in `pylock.toml` ([#&#8203;13132](astral-sh/uv#13132))
-   Fix display name for `uvx --version` ([#&#8203;13109](astral-sh/uv#13109))
-   Restore handling of authentication when encountering redirects ([#&#8203;13050](astral-sh/uv#13050))
-   Respect build options (`--no-binary` et al) in `pylock.toml` ([#&#8203;13134](astral-sh/uv#13134))
-   Use `upload-time` rather than `upload_time` in `uv.lock` ([#&#8203;13176](astral-sh/uv#13176))

##### Documentation

-   Changed `fish` completions append `>>` to overwrite `>` ([#&#8203;13130](astral-sh/uv#13130))
-   Add `pylock.toml` mentions where relevant ([#&#8203;13115](astral-sh/uv#13115))
-   Add ROCm example to the PyTorch guide ([#&#8203;13200](astral-sh/uv#13200))
-   Upgrade PyTorch guide to CUDA 12.8 and PyTorch 2.7 ([#&#8203;13199](astral-sh/uv#13199))

### [`v0.6.17`](https://github.com/astral-sh/uv/releases/tag/0.6.17)

[Compare Source](astral-sh/uv@0.6.16...0.6.17)

#### Release Notes

##### Preview features

-   Add PyTorch v2.7.0 to GPU backend ([#&#8203;13072](astral-sh/uv#13072))

##### Bug fixes

-   Avoid panic for invalid Python versions ([#&#8203;13077](astral-sh/uv#13077))
-   Block scripts from overwriting `python` ([#&#8203;13051](astral-sh/uv#13051))
-   Check distribution names to handle invalid redirects ([#&#8203;12917](astral-sh/uv#12917))
-   Check for mismatched package and distribution names on resolver thread ([#&#8203;13088](astral-sh/uv#13088))
-   Fix panic with invalid last character in PEP 508 name ([#&#8203;13105](astral-sh/uv#13105))
-   Reject `requires-python` even if not listed on the index page ([#&#8203;13086](astral-sh/uv#13086))

#### Install uv 0.6.17

##### Install prebuilt binaries via shell script

```sh
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/astral-sh/uv/releases/download/0.6.17/uv-installer.sh | sh
```

##### Install prebuilt binaries via powershell script

```sh
powershell -ExecutionPolicy Bypass -c "irm https://github.com/astral-sh/uv/releases/download/0.6.17/uv-installer.ps1 | iex"
```

#### Download uv 0.6.17

|  File  | Platform | Checksum |
|--------|----------|----------|
| [uv-aarch64-apple-darwin.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-aarch64-apple-darwin.tar.gz) | Apple Silicon macOS | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-aarch64-apple-darwin.tar.gz.sha256) |
| [uv-x86\_64-apple-darwin.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-x86\_64-apple-darwin.tar.gz) | Intel macOS | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-x86\_64-apple-darwin.tar.gz.sha256) |
| [uv-aarch64-pc-windows-msvc.zip](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-aarch64-pc-windows-msvc.zip) | ARM64 Windows | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-aarch64-pc-windows-msvc.zip.sha256) |
| [uv-i686-pc-windows-msvc.zip](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-i686-pc-windows-msvc.zip) | x86 Windows | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-i686-pc-windows-msvc.zip.sha256) |
| [uv-x86\_64-pc-windows-msvc.zip](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-x86\_64-pc-windows-msvc.zip) | x64 Windows | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-x86\_64-pc-windows-msvc.zip.sha256) |
| [uv-aarch64-unknown-linux-gnu.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-aarch64-unknown-linux-gnu.tar.gz) | ARM64 Linux | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-aarch64-unknown-linux-gnu.tar.gz.sha256) |
| [uv-i686-unknown-linux-gnu.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-i686-unknown-linux-gnu.tar.gz) | x86 Linux | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-i686-unknown-linux-gnu.tar.gz.sha256) |
| [uv-powerpc64-unknown-linux-gnu.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-powerpc64-unknown-linux-gnu.tar.gz) | PPC64 Linux | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-powerpc64-unknown-linux-gnu.tar.gz.sha256) |
| [uv-powerpc64le-unknown-linux-gnu.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-powerpc64le-unknown-linux-gnu.tar.gz) | PPC64LE Linux | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-powerpc64le-unknown-linux-gnu.tar.gz.sha256) |
| [uv-s390x-unknown-linux-gnu.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-s390x-unknown-linux-gnu.tar.gz) | S390x Linux | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-s390x-unknown-linux-gnu.tar.gz.sha256) |
| [uv-x86\_64-unknown-linux-gnu.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-x86\_64-unknown-linux-gnu.tar.gz) | x64 Linux | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-x86\_64-unknown-linux-gnu.tar.gz.sha256) |
| [uv-armv7-unknown-linux-gnueabihf.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-armv7-unknown-linux-gnueabihf.tar.gz) | ARMv7 Linux | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-armv7-unknown-linux-gnueabihf.tar.gz.sha256) |
| [uv-aarch64-unknown-linux-musl.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-aarch64-unknown-linux-musl.tar.gz) | ARM64 MUSL Linux | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-aarch64-unknown-linux-musl.tar.gz.sha256) |
| [uv-i686-unknown-linux-musl.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-i686-unknown-linux-musl.tar.gz) | x86 MUSL Linux | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-i686-unknown-linux-musl.tar.gz.sha256) |
| [uv-x86\_64-unknown-linux-musl.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-x86\_64-unknown-linux-musl.tar.gz) | x64 MUSL Linux | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-x86\_64-unknown-linux-musl.tar.gz.sha256) |
| [uv-arm-unknown-linux-musleabihf.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-arm-unknown-linux-musleabihf.tar.gz) | ARMv6 MUSL Linux (Hardfloat) | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-arm-unknown-linux-musleabihf.tar.gz.sha256) |
| [uv-armv7-unknown-linux-musleabihf.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-armv7-unknown-linux-musleabihf.tar.gz) | ARMv7 MUSL Linux | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-armv7-unknown-linux-musleabihf.tar.gz.sha256) |

</details>

---

### Configuration

📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 **Ignore**: Close this MR and you won't be reminded about this update again.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box

---

This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4yNTcuOCIsInVwZGF0ZWRJblZlciI6IjM5LjI2NC4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJSZW5vdmF0ZSBCb3QiXX0=-->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

breaking A breaking change

Projects

None yet

Development

Successfully merging this pull request may close these issues.

uvx logging and behavior confusing when using binary name instead of package name

3 participants