## Summary
Closes#7841. If there are other env vars that would also benefit from
this value parser, please let me know and I can add them to this PR.
## Test Plan
When running the same example from the linked issue, it now works:
```
UV_PYTHON= cargo run -- init x
Compiling ...
Finished `dev` profile [unoptimized + debuginfo] target(s) in 29.06s
Running `target/debug/uv init x`
Initialized project `x` at `/Users/krishnanchandra/Projects/uv/x`
```
## Summary
This PR adds support for the `UV_FIND_LINKS` environment variable as an
alternative to the `--find-links` command-line option, as requested in
#1839.
## Test Plan
A unit test was added to validate that setting `UV_FIND_LINKS` provided
the same result as a link provided with the `--find-links` command-line
option.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## Summary
This is a trivial, one line documentation change that fixes the
following documentation bug.
The current documentation suggests this for adding a git dependency
```
# Add a git dependency
uv add requests --git https://github.com/psf/requests
```
Executing what is suggested with `uv` version `0.4.18` results in this
error message
```
uv add requests --git https://github.com/psf/requests
error: unexpected argument '--git' found
```
The working approach is to add the git depency like this:
```
uv add git+https://github.com/psf/requests
```
## Test Plan
I manually tested the command suggested currently in the guide against
my change.
Unlike `cp36-...`, which requires exactly CPython 3.6, `py36-none` is
compatible with all versions starting at Python 3.6.
Note that `py3x-none` should not be used. Instead, use `py3-none` with
`requires-python`.
Fixes#7800
## Summary
PythonDownloadKey (cpython-3.13.0rc3-darwin-aarch64-none) and
PlatformTriple in `fetch-download-metadata.py` have a slight
inconsistency in the ordering of `os` and `arch`. In PythonDownloadKey,
`os` precedes `arch`, while in PlatformTriple, `arch` comes before
`platform` (equivalent to os). This difference in ordering affects the
sorting logic, giving arch higher priority than platform in the
`download-metadata.json` file, leading to a little bit of unexpected
order of entries.
Before:
<img width="676" alt="image"
src="https://github.com/user-attachments/assets/adb24a2e-da70-4a09-a702-4b5d71600b2c">
After:
<img width="725" alt="image"
src="https://github.com/user-attachments/assets/c6c76e6a-d3fd-43dc-bfb0-b3a4a3fe2b6b">
## Summary
If a supported environment includes a Python marker, we don't simplify
it out, despite _storing_ the simplified markers. This PR modifies the
validation code to compare simplified to simplified markers.
Closes https://github.com/astral-sh/uv/issues/7876.
It used to report:
```
» mypy
python/uv/_build_backend.py:40: error: Incompatible types in assignment (expression has type "list[str]", variable has type "CompletedProcess[bytes]") [assignment]
python/uv/_build_backend.py:41: error: Value of type "CompletedProcess[bytes]" is not indexable [index]
python/uv/_build_backend.py:46: error: Value of type "CompletedProcess[bytes]" is not indexable [index]
Found 3 errors in 1 file (checked 6 source files)
```
So, I had to fix this problem by renaming the `result` var.
## Summary
When using `uv tree --package foo`, an extra empty line appears at the
beginning, which seems unnecessary since `uv tree` without the package
option doesn’t have this. It’s possible that the intention was to add
separation between packages, i.e. the correct implementation shoule be:
```rust
if !std::mem::take(&mut first) {
lines.push(String::new());
}
```
Even if corrected, this extra spacing might be redundant as `uv tree`
doesn’t include these empty lines between packages by default.
```console
$ uv init project
$ cd project
$ uv init foo
$ uv tree
Using CPython 3.12.5
Resolved 2 packages in 1ms
foo v0.1.0
project v0.1.0
$ uv tree --package project
Using CPython 3.12.5
Resolved 2 packages in 1ms
project v0.1.0
```
## Summary
Closes https://github.com/astral-sh/uv/issues/6972
This is not breaking since `MACOSX_DEPLOYMENT_TARGET` will stay the same
(currently defaulting to 10.12) so a
`uv-x.y.z-py3-none-macosx_10_12_x86_64.whl` will still be built
<!--
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
Documentation for GitLab integration, reliant on the new tags introduced
in https://github.com/astral-sh/uv/pull/6053
## Test Plan
<!-- How was it tested? -->
---------
Co-authored-by: David Fritzsche <9479371+davidfritzsche@users.noreply.github.com>
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
Closes https://github.com/astral-sh/uv/issues/4931.
## Test Plan
Tried running the following commands locally to make sure that all cases
work:
```
unset PAGER
cargo run -- help venv
```
With no pager set, `uv` correctly finds `less` on the system as it did
before and passes the help output to it.
---
```
PAGER= cargo run -- help venv
```
This correctly prints out to stdout and does not use any pager.
---
```
PAGER=most cargo run -- help venv
```
This correctly opens the `most` pager as shown below:
<img width="1917" alt="Screenshot 2024-07-27 at 5 14 42 PM"
src="https://github.com/user-attachments/assets/dfaa5a83-b47e-4f5c-9be1-b0b1e9818932">
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
We now display the "Did you mean `python-dotenv`?"-style errors on build
failure, rather than in `uv add`. This is less opinionated and couples
us less to specific content in the registry.
## Test Plan
Would it be okay to expose this struct? We currently use our own
ResolveProvider, and it would be nice to use the `FlatDistributions` for
easy `VersionMap` creation.
Thanks!
