Part of https://github.com/astral-sh/uv/issues/4392
We shouldn't link to PyPI, and dropping the workspace-level
documentation link should mean that we get the auto-generated `docs.rs`
links.
Resolves https://github.com/astral-sh/uv/issues/16732
This diff treats extensionless files that contain
[PEP 723](https://peps.python.org/pep-0723/) metadata as scripts when
resolving `--with-requirements`, so inline metadata works even when the
script doesn’t end in `.py`.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
Currently, it's possible for `uv export` to overwrite someones
`pyproject.toml`. This diff simply rejects project files passed in with
`-o`, so we avoid doing that.
---------
Co-authored-by: konstin <konstin@mailbox.org>
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## Summary
Small nit, but I wanted to avoid doing this access in the hot path.
(Probably not important in practice.)
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
I initially thought I didn't need this, but in some contexts, the
workspace member name is not useful at all and I just want to iterate
over the paths without composing with `uv workspace dir --package
<name>`
Resolves https://github.com/astral-sh/uv/issues/16719
`uv add` collapses multiple spaces before inline comments in
`[project.dependencies]`, causing unrelated diffs and moving comments
onto the wrong columns. This diff captures the exact whitespace padding
that preceded each end-of-line comment when parsing the array and reuses
it when formatting.
---------
Co-authored-by: konstin <konstin@mailbox.org>
<!--
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
#12175 changed the behavior of `on_request_complete` when stderr is not
a tty to output `Downloading`/`Uploading` (via `Direction::as_str`).
This fixes it to output `Downloaded`/`Uploaded` again.
## Test Plan
Tested locally to verify new output.
Old:
```
$ uv sync --no-cache 2>&1 | tee /dev/null
Using CPython 3.14.0
Creating virtual environment at: .venv
Resolved 12 packages in 19ms
Downloading numpy (15.8MiB)
Downloading matplotlib (9.4MiB)
Downloading fonttools (4.6MiB)
Downloading pillow (6.7MiB)
Downloading kiwisolver (1.4MiB)
Downloading kiwisolver
Downloading fonttools
Downloading pillow
Downloading matplotlib
Downloading numpy
```
New:
```
$ uv sync --no-cache 2>&1 | tee /dev/null
Using CPython 3.14.0
Creating virtual environment at: .venv
Resolved 12 packages in 3ms
Downloading numpy (15.8MiB)
Downloading fonttools (4.6MiB)
Downloading matplotlib (9.4MiB)
Downloading kiwisolver (1.4MiB)
Downloading pillow (6.7MiB)
Downloaded kiwisolver
Downloaded pillow
Downloaded fonttools
Downloaded matplotlib
Downloaded numpy
```
Dependabot appears to run a proxy which intercepts all requests and adds
credentials — credentials are _not_ provided via the CLI or environment
variables and there's no way for a user to do so. This means that when
`authenticate = "always"` is used (or when the index URL is on a pyx
domain), uv will fail even though Dependabot may intercept the request
and add credentials.
See
https://github.com/dependabot/dependabot-core/#private-registry-credential-management
I'm a little wary here, in the sense that it might be silly to have a
command that does something so simple that's covered by `uv workspace
metadata`? but I think this could be stabilized much faster than `uv
workspace metadata` and makes it easier to write scripts against
workspace members.
---------
Co-authored-by: liam <liam@scalzulli.com>
Resolves https://github.com/astral-sh/uv/issues/16693
[`PEP 639`](https://peps.python.org/pep-0639/#add-license-files-key)
requires build tools to error if any user-specified
`project.license-files` glob fails to match a file, but uv currently
allows the build to succeed and produces empty `.dist-info/licenses/`
directories.
This PR enforces the spec by tracking matches for each glob during
metadata generation, raising a clear
validation error when one is unmatched.
This allows us to suggest `uv python install --upgrade 3.14` as the
canonical way to get the latest patch version of a given Python
regardless of whether it is installed already. Currently, you can do `uv
python upgrade 3.14` and it will install it, but I'd like to remove that
behavior as I find it very surprising.
I noticed this when working on
https://github.com/astral-sh/uv/pull/16697.
[PEP 639](https://peps.python.org/pep-0639/#add-license-files-key)
expects tools to ship license texts as UTF‑8, but previously `uv build`
would quietly include any binary blob listed under
`project.license-files`.
I have no clue what is going on with `rustfmt` for this file, but it
seems that when I add the check, it wants to reformat a bunch of
surrounding stuff.
The relevant part to look at is:
```rust
for license_file in &license_files {
let file_path = root.join(license_file);
let bytes = fs_err::read(&file_path)?;
if str::from_utf8(&bytes).is_err() {
return Err(ValidationError::LicenseFileNotUtf8(license_file.clone()).into());
}
}
```
where we validate all collected license files before proceeding.
---------
Co-authored-by: konstin <konstin@mailbox.org>
## Summary
As described in https://github.com/astral-sh/uv/issues/12229, `pip
install` with `--target` or `--prefix` seem like they should install the
necessary python version if it doesn't exist, but they currently don't.
Most minimal reproduction is something like:
```
> uv python uninstall 3.13
...
> uv pip install anyio --target target-dir --python 3.13
error: No interpreter found for Python 3.13 in virtual environments, managed installations, or search path
```
This also fails without `--target`, but a venv is expected in that case,
so the with `--target`/`--prefix` is the only version that needs to be
fixed. The same mechanism occurs for `uv pip sync` as well.
## Test Plan
Added tests for install and sync that failed before fix and now pass.
---------
Signed-off-by: Mikayla Thompson <mrt@mikayla.codes>
## Summary
Fixes `--default` not creating default executable links for pre-release
Python versions.
When using `--default` with a pre-release version like `3.15.0a1`, the
code was checking `matches_installation()` against the download request
instead of the original user request. This caused the check to fail
since the download request doesn't match pre-release versions the same
way.
Changed it to use `installation.satisfies(&first_request.request)` when
`--default` is used, which checks against the original user request.
Fixes#16696
## Test Plan
Added `python_install_default_prerelease` test that installs Python 3.15
with `--default` and verifies all three executable links (`python3.15`,
`python3`, `python`) are created. The test skips gracefully if 3.15
isn't available.
All existing tests pass.
<!--
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 typo in crates/uv-virtualenv/README.md
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
<!-- How was it tested? -->
No need.
Signed-off-by: bigmoonbit <bigmoonbit@outlook.com>
## Summary
Two tests were failing when run with `SHELL=fish`:
1. `create_venv_current_working_directory` failed because the "activate"
filter didn't apply properly when the venv was in the CWD. This PR fixes
the filter.
2. `tool_install_warn_path` failed because the messages are different
between fish and bash. This PR hardcodes `SHELL=fish`.
## Test Plan
CI
Follow-up from https://github.com/astral-sh/uv/pull/16690, in `uv` every
command should be using `write!(...)/writeln!(...)` with the `Printer`
abstraction instead of bypassing control with the standard printing
functions. This lint ensures that.
## Summary
This test isn't useful on non-arm64 macs, and it outright fails if
rosetta isn't installed.
## Test Plan
Run it on my rosetta-stripped macbook
Resolves https://github.com/astral-sh/uv/issues/16616
This PR detects managed prerelease interpreters during discovery and
warns when a matching stable build is available, wiring the new helper
into `PythonInstallation::find`, `find_best`, and `find_or_download`.
## Summary
1. Discussed in review of #16678 that println should be replaced by
using `printer`. The `println` pattern was pretty consistent across all
the `dir` commands, so I've updated all of them in this PR (there are
some usages of `println` outside of `uv/src/commands` that I didn't
touch -- the use cases there seemed more complex and nuanced).
2. I missed two comments in the previous PR before merging, so updates
from those are in here as well.
## Test Plan
No behavior changes, existing tests for all commands pass.
---------
Signed-off-by: Mikayla Thompson <mrt@mikayla.codes>
Addresses https://github.com/astral-sh/uv/issues/13636
Prints the path to the workspace root by default, and any of the child
packages if requested.
I looped it into the same preview flag as `workspace metadata`, given
how closely related they are.
## Summary
```
─> uv workspace dir
/Users/mikayla/code/uv/dev-envs
─> uv workspace dir --package foo-proj
/Users/mikayla/code/uv/dev-envs/foo-proj
─> uv workspace dir --package bar-proj
error: Package `bar-proj` not found in workspace.
```
## Test Plan
Unit tests added.
---------
Signed-off-by: Mikayla Thompson <mrt@mikayla.codes>
Co-authored-by: Zanie Blue <contact@zanie.dev>
Resolves https://github.com/astral-sh/uv/issues/16427
This PR updates `uv version --bump` so you can pin the exact number
you’re targeting, i.e. `--bump patch=10` or `--bump dev=42`. The
command-line interface now parses those `component=value` flags, and the
bump logic actually sets the version to the number you asked for.
This adds the scaffolding for a `uv workspace metadata` command, as an
equivalent to `cargo metadata`, for integration with downstream tools. I
didn't do much here beyond emit the workspace root path and the paths of
the workspace members. I explored doing a bit more in #16638, but I
think we're actually going to want to come up with a fairly
comprehensive schema like `cargo metadata` has. I've started exploring
that too, but I don't have a concrete proposal to share yet.
I don't want this to be a top-level command because I think people would
expect `uv metadata <PACKAGE>` to show metadata about arbitrary packages
(this has been requested several times). I also think we can do other
things in the workspace namespace to make trivial integrations simpler,
like `uv workspace list` (enumerate members) and `uv workspace dir`
(show the path to the workspace root).
I don't expect this to be stable at all to start. I've both gated it
with preview and hidden it from the help. The intent is to merge so we
can iterate on it as we figure out what integrations need.
Addresses https://github.com/astral-sh/uv/issues/15790
## Summary
After discussion, the functionality of `--project` vs `--directory` was
quite unclear in this case, so deprecating `--project` for `init` is
probably the clearest behavior option. This is a breaking change, so it
requires being under preview before being rolled out fully.
Included in the PR now:
- new feature flag (`init --project` is deprecated if `--preview` or
`--preview-features deprecate-project-for-init` are provided)
- tests (for `--directory` behavior, as well as the current warning and
future error)
- documentation updated in docs/concepts/projects/init.md
---------
Signed-off-by: Mikayla Thompson <mrt@mikayla.codes>
<!--
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
Similarly to #16529 that adds `UV_NO_GROUP`, this adds
`UV_NO_DEFAULT_GROUPS` that does the same as `--no-default-groups`. This
can be useful on the CI, to disable default groups on a job without
having to set the argument in all commands that could trigger a sync
(for instance
[here](8757b318e9/.github/workflows/main.yml (L105-L116))).
## Test Plan
Snapshot tests.
---------
Co-authored-by: samypr100 <3933065+samypr100@users.noreply.github.com>
## Summary
At present, we only have support for the detail routes (e.g.,
`https://pypi.org/simple/requests`), but not the top-level index route
(e.g., `https://pypi.org/simple/`). I need this for some downstream work
so pulling it into its own PR.
## Summary
These are present on the PyTorch index, but only at very old versions.
The PyPI versions are newer, and seemingly these don't need to be built
against CUDA, etc.
Closes https://github.com/astral-sh/uv/issues/16651.
Resolves https://github.com/astral-sh/uv/issues/16295
This PR updates the Conda base-environment heuristic to recognize
Pixi-managed environments by checking for the `conda-meta/pixi` marker
file. Pixi default environments now resolve as isolated child
environments instead of system installations, restoring the expected uv
pip behavior without the `--system` flag.
`.rsrc` is the idiomatic way of storing metadata and non-code resources
in PE
binaries. This should make the resulting binaries more robust as they
are no longer
dependent on the exact location of a certain magic number.
Addresses: #15022
## Test Plan
Existing integration test for `uv-trampoline-builder` + addition to
ensure robustness
to code signing.
---------
Co-authored-by: samypr100 <3933065+samypr100@users.noreply.github.com>
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
Now that we perform this fast-path in
`crates/uv-distribution/src/source/mod.rs`, I _think_ the fast-path here
is no longer used? In my testing, we only actually took this path when
the fast-path _already_ failed (and thus it would fail again, wasting
time).
<!--
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
Fixed a typo in the docs.
Regenerated the docs, with the fix.
<!-- What's the purpose of the change? What does it do, and why? -->
## Summary
Fix incomplete value_type attribute for default-groups field in the
ToolUv struct schema definition. The value_type was missing its value,
which should be str | list[str] to reflect that default-groups can
accept either the literal "all" or a list of group names. (#16574)
Resolves https://github.com/astral-sh/uv/issues/16433
When `uv init` infers a project name from the working directory,
directories with characters outside the PEP 503 rules produced the
generic “Not a valid package or extra name” message that didn’t explain
the source of the problem. This change intercepts that failure, reports
whether the current or explicit target directory caused it, and tells
the user to supply an explicit `--name`.
<!--
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? -->
This PR removes the crate fs2 and updates Rust version to 1.89.
*Why?*
Crate fs2 is unmaintained for a long time now and has unfixed issues.
Especially it doesn't build on AIX, which is the reason I started fixing
it.
*How?*
I removed fs2 and replaced it by std:fs:File methods.
## Test Plan
<!-- How was it tested? -->
- I built it on Windows and AIX only.
- I did not test the artifacts.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
Implement `uv cache size` to output the cache directory size in raw
bytes by default, with a `--human` option for human-readable output.
close#15821
<!-- How was it tested? -->
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## Summary
This is an enhancement that makes the cli flag `--no-sources` an
environment variable - "UV_NO_SOURCES"
Why is this a relevant change?
When working across different environments, in our case remote vs local,
we often have our packages hosted in a artifact registry but when
developing locally we build our packages from github. This results in us
using the uv.tool.sources table quite a bit however this then also
forces us to use `--no-sources` for all our remote work.
This change enables us to set an environment variable once and to never
have to type --no-sources after every uv run command again.
## Test Plan
Expanded on the current --no-sources tests, to test when
UV_NO_SOURCES=true/false the behaviour is the same as the flag.
Additionally ensured that the cli overrides the env variable.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
For https://github.com/astral-sh/uv/issues/16336. We previously weren't
telling the user which file is responsible for rebuilding.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
Resolves https://github.com/astral-sh/uv/issues/16496
This PR updates the resolver so `build-system` dependency failures
surface prerelease hints even when prerelease selection is fixed. When a
build dependency only has prerelease candidates, or the requested
version explicitly includes a prerelease marker, we now emit a tailored
hint explaining that build environments can’t auto-enable prereleases
and describing how to opt in.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## Summary
Deserialize project name into both a String and a ProjectName, this way
we can keep using the normalized name elsewhere while respecting the
original name from the `pyproject.toml` file
This PR addresses issue #16547
## Test Plan
I added a new test for this, and I ran the test suite in the
`metadata.rs` file.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## Summary
This PR adds an `exclude-dependencies` setting that allows users to omit
a dependency during resolution. It's effectively a formalized version of
the `flask ; python_version < '0'` hack that we've suggested to users in
various issues.
Closes#12616.
It's too common to set `FORCE_COLOR` in CI which then breaks consumption
of the token.
This is actually specific to `pyx.dev`, as we print passwords without
coloring.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
<!--
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
Improve readability of progress bars by drawing the right portions in
dimmed black instead of dimmed green. This makes it much easier to
distinguish from the left (finished) part, which is drawn in green.
Fixes#6908.
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
Tested locally, looks as follows:
<img width="1100" height="731" alt="white"
src="https://github.com/user-attachments/assets/2a396e96-27ef-41ed-8b03-a0de2061af12"
/>
<img width="1100" height="731" alt="black"
src="https://github.com/user-attachments/assets/85d03a3a-a1dc-4389-9e51-fd486e60e067"
/>
The `home_dir` function in std was deprecated for some years for reading
`HOME` on Windows. It has recently been fixed and undeprecated:
https://github.com/rust-lang/rust/pull/132515
Conversely, the Cargo maintainers want us to move away from the home
crate (https://github.com/rust-lang/cargo/tree/master/crates/home):
> Note: This has been fixed in Rust 1.85 to no longer use the HOME
environment variable on Windows. If you are still using this crate for
the purpose of getting a home directory, you are strongly encouraged to
switch to using the standard library's home_dir instead. It is planned
to have the deprecation notice removed in 1.87.
>
> This crate further provides two functions, cargo_home and rustup_home,
which are the canonical way to determine the location that Cargo and
rustup store their data.
>
> See rust-lang/rust#43321.
>
> > This crate is maintained by the Cargo team, primarily for use by
Cargo and Rustup and not intended for external use. This crate may make
major changes to its APIs or be deprecated without warning.
When https://github.com/lunacookies/etcetera/pull/36 merges, we can
remove the home crate from our dependency tree.
## Summary
Extend the existing GitHub Gist URL support from #15058 to handle URLs
that redirect to Gists.
`reqwest` already handled generic URL redirects for us (note this
redirects directly to the `.py` on `gist.githubusercontent.com`):
~/git/uv $ uv run
c28a4bf0cb/hello.py
hello world!
But running a URL that redirected to a Gist's "main page" (a bit.ly link
leading to a Gist, etc.) did not:
~/git/uv $ uv run
https://httpbin.org/redirect-to?url=https://gist.github.com/twilligon/4d878a4d9550a4f1df258cde1f058699
File "/tmp/scriptNodt3Q.py", line 87
<title>hello.py · GitHub</title>
But if we have `reqwest` follow redirects *before* `resolve_gist_url`,
we can handle this fine:
~/git/uv $ target/debug/uv run
https://httpbin.org/redirect-to?url=https://gist.github.com/twilligon/4d878a4d9550a4f1df258cde1f058699
hello world!
## Test Plan
I'd write an automated test but that'd require network access since
wiremock doesn't seem to support mocking specific hostnames like
`gist.github.com`. As manual tests go, I basically did the above,
testing with several redirectors to both generic and Gist URLs.
## Summary
Without this, a user who does `uv auth login ...` will retry against the
service's status endpoint forever. This probably isn't what they
intended (they probably walked away from their machine), so we end their
login initiation session after 60 retries. Since we do a retry every
second, this gives them no less than a minute to complete a login (which
should be more than enough).
## Test Plan
We don't have browser-negotiated login tests at the moment in CI, but
I've tested this locally:
```console
% ./target/debug/uv auth login pyx.dev
Logging in with https://api.pyx.dev/auth/cli/login/REDACTED
error: Login session timed out
```
(That took well over a minute, so 60s is a lower bound assuming a very
optimal network roundtrip on each poll.)
---------
Signed-off-by: William Woodruff <william@astral.sh>
Zanie Blue
William Woodruff
Charlie Marsh
konsti
liam
github-actions[bot]
Tom Schafer
Ryan Blue
samypr100
Meitar Reihan
Mikayla Thompson
Oshadha Gunawardena
Zsolt Dollenstein
bigmoonbit
Mathieu Kniewallner
Pavel Logan Dikov
Haaris Rahman
Les Freire
renovate[bot]
Michael Richter
chisato
Blair Allan
Christian Asch
Alexander Vandenbulcke
Clemens Brunner
twilligon