## Summary
We accept `pylock.toml` as a requirements file (e.g., `uv sync
pylock.toml` or `uv pip install -r pylock.toml`). When you provide a
`pylock.toml` file, we don't allow you to provide other requirements, or
constraints, etc. And you can only provide one `pylock.toml` file, not
multiple.
We might want to remove this from `uv pip install` for now, since `pip`
may end up with a different interface (whereas `uv pip sync` is already
specific to uv), and most of the arguments aren't applicable (like
`--resolution`, etc.). Regardless, it's behind `--preview` for both
commands.
## Summary
This PR adds `uv export` support for [PEP
751](https://peps.python.org/pep-0751). We don't yet expose a way to
consume the generated lockfile, but it's a first step.
The logic to go from `uv.lock` to "flat set of packages to include, with
markers telling us when to include them" is all shared with the
`requirements.txt` export (and extracted in
https://github.com/astral-sh/uv/pull/12956). So most of the code is just
converting from our internal types to the PEP 751 schema.
As I suspected quite some time ago
(https://github.com/astral-sh/uv/pull/6738#issuecomment-2315466033),
it's problematic that we don't handle _every_ signal here. This PR adds
handling for all of the Unix signals except `SIGCHLD`, `SIGIO`, and
`SIGPOLL` which seem incorrect to forward. Also notable, we _cannot_
handle `SIGKILL` so if someone sends that to the PID instead of the
PGID, they will leave dangling subprocesses.
Instead, we could use `exec` and avoid this handling. However, we'd lose
the ability to add nice error message on failure (e.g., as someone is
trying to add in https://github.com/astral-sh/uv/pull/12201) and, more
critically, we'd need to figure out how to clean up resources properly
(i.e., temporary directories) which currently happens on `Drop`. In the
long-term, we'll probably want an option to use `exec` — but we'll need
to figure out when to clean up resources or accept that they will
dangle. This was last discussed in
https://github.com/astral-sh/uv/issues/3095 — discussion on that
approach should continue there.
A note on the implementation: I spent time time trying to write the
handler using a tokio stream, so we could dynamically iterate over a
list of signals instead of copy/pasting the implementation — I couldn't
get it to work though and it didn't seem critical.
Closes https://github.com/astral-sh/uv/issues/12830
## Summary
Before:
```console
$ uv python list py --managed-python
error: Interpreter discovery for `executable name `py`` requires `search path` but only only managed is allowed
```
After:
```console
$ uv python list py --managed-python
error: Interpreter discovery for `executable name `py`` requires `search path` but only `only managed` is allowed
```
Closes: #4567
## Summary
When adding a package with Git reference options (`--rev`, `--tag`,
`--branch`) that already has a Git source defined, use the existing Git
URL with the new reference instead of reporting an error.
This allows commands like `uv add requests --branch main` to work when
requests is already defined with a Git source in the project
configuration.
Previously, you would need to provide the whole Git url again for this
to work:
```bash
uv add git+https://github.com/psf/requests --branch main
```
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
- [x] Add unit tests for project
- [x] Add unit tests for script
- [x] Tested locally for project and script environments like below
### Testing Project
In a directory using the `uv` executable from this PR (via replacing
every `uv` with `cargo run --`) initialize a project and virtual
environment
```bash
uv init
uv venv
```
move into the environment
```bash
# on mac
source .venv/bin/activate
```
and add a dependency with a git url
```bash
uv add git+https://github.com/Textualize/rich --branch master
```
Then change the branch of the project to see that the branch can be
changed without need of the whole git url:
```bash
uv add rich --branch py310
```
### Testing Script
Create the following file, e.g. `script.py`:
```python
import time
from rich.progress import track
print("Starting")
for i in track(range(20), description="For example:"):
time.sleep(0.05)
print("Done")
```
Now using `uv` (referencing the executable of this PR) add the
dependency
```bash
uv add --script script.py 'git+https://github.com/Textualize/rich' --branch master
```
and check we can execute the script:
```bash
uv run script.py
```
To test the change update the branch
```bash
uv add --script script.py rich --branch py310
```
and check that the dependency is updated and the script is executed:
```bash
uv run script.py
```
<!-- How was it tested? -->
----
This is my first time contributing to `uv` (yay, 🤗) so let me know if
there is something obvious i am missing.
Unit tests will follow soon.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## Summary
This is included in PEP 751, so we lose it when converting from
`uv.lock`. I think it's a good piece of information to include in the
`uv.lock` anyway.
I noticed in the trace output that we weren't obfuscating the
`Credentials` password in a trace message. This PR creates a `Password`
newtype with a custom `Debug` implementation.
uv was failing to authenticate on 302 redirects when credentials were
available. This was because it was relying on `reqwest_middleware`'s
default redirect behavior which bypasses the middleware pipeline when
trying the redirect request (and hence bypasses our authentication
middleware). This PR updates uv to retrigger the middleware pipeline
when handling a 302 redirect, correctly using credentials from the URL,
the keyring, or `.netrc`.
Closes#5595Closes#11097
Fixes#12914.
When `PythonDownloadRequest` does not have the `implementation` set, do
not set it to CPython when calling `fill`, otherwise only CPython
interpreters are shown when listing interpreters available for download,
with `uv python list`.
## Summary
This PR simplifies the version formatting by replacing `.white()` with
`.cyan()` styling for consistency.
Resolves#12940
## Test Plan
I manually recreated the code and tested it with this patch:
```diff
diff --git i/crates/uv/src/lib.rs w/crates/uv/src/lib.rs
index b9c01b002..cf051351f 100644
--- i/crates/uv/src/lib.rs
+++ w/crates/uv/src/lib.rs
@@ -1019,6 +1019,20 @@ async fn run(mut cli: Cli) -> Result<ExitStatus> {
}) => commands::self_update(target_version, token, printer).await,
#[cfg(not(feature = "self-update"))]
Commands::Self_(_) => {
+ eprintln!("{}: {}", "error".cyan().bold(), "fake error message");
+
+ let version_information = format!(
+ "from {} to {}",
+ "v0.1.1".bold().cyan(),
+ "v0.1.2".bold().cyan(),
+ );
+ eprintln!(
+ "{}{} Upgraded uv {}! {}",
+ "success".green().bold(),
+ ":".bold(),
+ version_information,
+ format!("https://github.com/astral-sh/uv/releases/tag/{}", "v0.1.2").cyan()
+ );
anyhow::bail!(
"uv was installed through an external package manager, and self-update \
is not available. Please use your package manager to update uv."
```
In a light terminal, this is what it looks like:
<img width="750" alt="image"
src="https://github.com/user-attachments/assets/dc0d283c-e845-41fb-9821-80b0a3f1c4fe"
/>
Closes#12929
## Summary
Untag the `config-settings` value to support JSON schema according to
the
[docs](https://docs.astral.sh/uv/reference/settings/#config-settings).
```toml
[tool.uv]
config-settings = { editable_mode = "compat" }
```
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
Verified using the "Even Better TOML" extension with paths to old and
new `uv.schema.json`.
## Notes
I could not reproduce the issue with either the `taplo` (on which Even
Better Toml is built, afaik) and `check-jsonschema` CLI tools; with both
old and new versions of the `uv.schema.json` validated the
`pyproject.toml`.
Maybe for these there is some additional regularization going on and
that's also how a breaking case ended up in the docs?
I'm unsure on how to test for this.
After about an hour, the Even better TOML VSCode extension was the only
way to reproduce failing validation.
Let me know if I can do something else.
<!-- How was it tested? -->
Currently, `uv init` works without a `git` executable, and with a
working `git` executable, but not with a broken `git`, be it from GitHub
Action's Windows CI or from the shim we insert.
`uv init` calls git twice: Once `git rev-parse` to check whether a git
repo already exists, and then `git init` (if there is no git repository
yet and no `--vcs none`).
By separately handling the cases where git failed during `git rev-parse`
doesn't work vs. where the is no repository when checking for an
existing repo work tree, we can avoid calling `git init` for broken git
and erroring. We have to hardcode the expected git command outputs to be
able to check.
