Added support for [tool.uv.preview-features] in TOML configs (#15767)

[j-helland]

Relates to (#15767)

Summary

Before this PR, specific preview features could only be specified via a comma-separated list in CLI --preview-features. Now, preview features can be specified as a list of strings in pyproject.toml or uv.toml. For example,

# pyproject.toml
[tool.uv]
preview-features = ["format"]

--preview and --no-preview take precedence over tool.uv.preview, which matches the previous semantics.
--preview-features will generally combine with tool.uv.preview-features with a couple of nuances:

• When tool.uv.preview = false, only --preview-features will be used. This allows the CLI to have precedence over the config.
• When tool.uv.preview = true, all features will be enabled (technically, --preview-features are combined with all features).

Alternatives Considered

From #15767 (comment):

setting tool.uv.preview-features.pylock = false would disable it, taking precedence over the feature potentially being enabled at a user level. If tool.uv.preview were changed to false, all preview features would be disabled, regardless of the content of tool.uv.preview-features.

I chose not to take this approach because it adds complexity and the semantics don't align with uv today. For example, --no-preview will currently take priority, even if pyproject.toml has uv.tool.preview = true. I think driving uv from the top-down like this is generally the right decision (and changing the semantics for a small feature like this would certainly not be).

Test Plan

• cargo nextest run
• cargo build
• New snapshot tests.

In addition to the above, I also tried a small test project:

pyproject.toml test

From the uv/ project root:

$ mkdir tmp && cd tmp
$ cargo run -- init

# Warning
$ cargo run -- format 
warning: `uv format` is experimental and may change without warning. Pass `--preview-features format` to disable this warning.
1 file left unchanged

# No warning
$ echo "\n[tool.uv]\npreview-features = [\"format\"]" >> pyproject.toml
$ cargo run -- format
1 file left unchanged

# `uv.toml` takes priority over `pyproject.toml`
$ echo "preview-features = []" >> uv.toml
warning: Found both a `uv.toml` file and a `[tool.uv]` section in an adjacent `pyproject.toml`. The following fields from `[tool.uv]` will be ignored in favor of the `uv.toml` file:
- preview-features
warning: `uv format` is experimental and may change without warning. Pass `--preview-features format` to disable this warning.
1 file left unchanged

[j-helland]

Some docker CI jobs failing, all due to

Error: missing API token, please run `depot login`
Error: failed with: Error: missing API token, please run `depot login`

I've checked other recent PRs and I'm seeing similar failures (example), so I suspect this is a transient issue not related to my changes.

[j-helland]

This being my first PR in uv, I'm especially open to any and all feedback / changes requested (not that I wouldn't be if it was my 500th 🙂). If there's anything I can do to make the review process easier, don't hesitate to let me know!

[zanieb]

Cool thanks!

Some quick high-level thoughts (I haven't looked at the code yet)

Passing --preview-features via CLI does NOT combine with uv.tool.preview-features, it overrides it completely. This behavior makes sense to me, otherwise there isn't a clear way to say "No, don't use your config feature X, use Y and Z instead".

I think we should actually combine them. If we get feedback that people need to be able to disable specific features, then the canonical way to do so in uv's interface would be to add a --no-preview-features <names> flag.

Don't worry about those Depot authentication failures — we're working with them to resolve those.

[j-helland]

I think we should actually combine them. If we get feedback that people need to be able to disable specific features, then the canonical way to do so in uv's interface would be to add a --no-preview-features flag.

Got it, thanks for explaining. That should be an easy fix, I’ll get to that later today.

[j-helland]

@zanieb I want to clarify one thing before submitting my revision. Suppose we pass --preview-features pylock with an underlying config like

preview = false
preview-features = ["format"]

1. Would the final set of features be format | pylock or would we prefer to take only pylock since uv.tool.preview = false?
2. Similarly, if tool.uv.preview = true, should any --preview-features merge into that de facto, resulting in all features being enabled?

I would intuitively expect that

1. We just take pylock when tool.uv.preview = false, ignoring the config features.
2. Extra --preview-features are swallowed by uv.tool.preview = true.

[j-helland]

I pushed what made intuitive sense to me:

1. We just take pylock when tool.uv.preview = false, ignoring the config features.
2. Extra --preview-features are swallowed by uv.tool.preview = true.

Happy to change this if requested!