In a similar way that #19860 needs to add a top-level script node to
represent dependencies of the script, it's been an outstanding issue
that we lack a top-level workspace node to represent dependency-groups
that are exclusive to the workspace.
Like other `--script` commands this tells uv to ignore the current
workspace and only handle the PEP 723 script at the given path, with its
own lock and venv.
## Summary
This is a continuation of the excellent work by @j-helland in #16452 and
#17202 and closes#15767.
This PR adds `preview-features` to `uv.toml` and `pyproject.toml`.
This field can be set to a boolean or to a list of features.
It is intended to supersede the `preview` setting itself, and conflicts
with it.
There's a little bit of complexity required to ensure that setting
either `preview` or `preview-features` is combined at the right point,
but it's also necessary to leave them split to accurately warn when a
`uv.toml` masks a `pyproject.toml` in the same directory.
Additionally there's complexity involved in making things work with
`deny_unknown_fields` and `flatten` (they're incompatible so require
manual flattening) and also this improves error messages somewhat.
Also (supersedes) closes#16452 and (supersedes) closes#17202.
## Test Plan
Tests taken from the original PR with some alterations and a bunch of
additional tests.
---------
Co-authored-by: j-helland <jonathan.w.helland@gmail.com>
Co-authored-by: Zanie Blue <contact@zanie.dev>
This is a field of particular interest to `ty`, especially if
`--isolated` or `--script` stuff is going on. Possibly also enables a
future where we don't necessarily store the workspace venv in the
project dir.
Adding it here first to establish it in the schema, further integrations
will be in followups.
## Summary
We landed this with #18936, so it probably makes sense to have _some_
docs for it. Not 100% sure if this is the best place, but it seems
pretty close 🙂
See #18781
Closes https://github.com/astral-sh/uv/issues/19519.
## Test Plan
NFC, docs only.
Signed-off-by: William Woodruff <william@yossarian.net>
[TOML 1.1](https://github.com/toml-lang/toml/releases/tag/1.1.0)
introduces support for new syntax that older tools with only TOML 1.0
support don't understand.
Usually, the user is either in control of which tools need to read the
TOML files or the TOML gets converted before publishing (for wheels:
`pyproject.toml` -> `METADATA`). The specific case where this doesn't
work is when a package manager that only support TOML 1.0 tries to build
the source distribution of a dependency. Build tools need to parse
`pyproject.toml` in source distributions to extract the `[build-system]`
table, and if any other part of the file contains TOML 1.1 syntax, they
fail to build. This generally doesn't trigger backtracking, so the user
is left with a failure when any (transitive) dependency in their
dependency tree has started using a single instance of TOML 1.1. Most
package managers, including pip, are implemented in Python and use
stdlib's tomllib, which only support TOML 1.0 up to including Python
3.14.
To work around this, we do a best-effort rewrite of `pyproject.toml` to
TOML 1.0 during source distribution builds.
This approach is inspired by Cargo, which has been successfully
rewriting published `Cargo.toml`s for many versions. While the `toml`
crate doesn't guarantee this downgrade always works
(https://github.com/toml-rs/toml/issues/1088), this crate is also used
by Cargo, and this best effort rewrite handles the biggest failure case:
Newlines and trailing commas in inline tables. Similarly following
Cargo, we also add a `pyproject.toml.orig` to the source distribution.
https://discuss.python.org/t/adopting-toml-1-1/105624 was inconclusive,
but a best-in-class tool should do this transformation.
---------
Co-authored-by: Tomasz (Tom) Kramkowski <tom@astral.sh>
## Summary
This follows the pattern we use for GCS and AWS: set
`UV_AZURE_ENDPOINT_URL`, then we use `AZURE_CLIENT_ID`,
`AZURE_TENANT_ID`, and `AZURE_FEDERATED_TOKEN_FILE` to sign requests to
that endpoint (or the CLI authentication, based on `reqsign`'s default
precedence).
Closes https://github.com/astral-sh/uv/issues/19420.
Make a new Bazel guide, that links to two of the most popular Bazel
rulesets that support uv. Move the Bazel specific authentication setup
to this new guide.
This is a followup to #19358
This is a very minor doc change but fixes a bug for diligent but
unknowing new users following the guide.
The UV guide on publishing to PyPI from GHA has a screenshot showing
that users reference a "release.yml" GHA workflow file when setting up a
new Trusted Publisher in PyPI. But the guide had users create a
"publish.yml" workflow file in their GitHub repository before this. PyPI
won't grant the expected token because the workflow names don't match
exactly across PyPI and GH, so the example bombs pretty hard.
Love all your work. Thanks for your help.
<!--
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? -->
## Test Plan
<!-- How was it tested? -->
<!--
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
As the title says
## Test Plan
N/A
## Summary
This PR enables users to set an `exclude-newer` override on a per-index
basis.
The priority is such that global `exclude-newer-package` has highest
priority, followed by `exclude-newer` on an index, followed by global
`exclude-newer`.
Closes https://github.com/astral-sh/uv/issues/16813.
A small typo:
uv init example --bare --> uv init example-bare --bare
<!--
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? -->
## Test Plan
<!-- How was it tested? -->
<!--
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
Add the explicit configuration for opting out a package out of
`--exclude-newer`. The docs mention this from
https://github.com/astral-sh/uv/pull/16854, but the actual
pyproject.toml configuration was missing. I found it from
https://github.com/astral-sh/uv/issues/12449#issuecomment-4170155721,
but this should be in the docs.
## Test Plan
uv run --only-group docs mkdocs serve -f mkdocs.yml
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
This expands `uv workspace metadata` with many of the fields that are
found in `uv.lock` so that we have a format with information about the
dependency graph/resolution that we're willing to call stable and have
people rely upon (rather than `uv.lock` which we'd rather you don't try
to interpret).
To a first approximation you can think of this as "uv.lock but
serialized to json" but with the fields a bit more limited for now (easy
to add later).
The biggest intentional divergence with uv.lock is that we favour
encoding the dependency graph in a form that looks more like our
internal "resolve" graph, in that hopes that it will simplify the work
of anyone doing analysis on the graph (we structure our internal graph
like this for a reason).
Specifically, the `resolve` field contains the entire dependency graph,
with packages desugarred into several different nodes. There are 4 kinds
of nodes (really 3, the build nodes will only be introduced when we
establish build-dependency locking):
* packages: `mypackage==1.0.0 @ registry+https://pypi.org/simple`
* extras: `mypackage[myextra]==1.0.0 @ registry+https://pypi.org/simple`
* groups: `mypackage:mygroup==1.0.0 @ registry+https://pypi.org/simple`
* build: `mypackage(build)==1.0.0 @ registry+https://pypi.org/simple`
package nodes hold additional metadata about the package itself, and ids
of the associated extra/group/build nodes.
---
A package like this:
```toml
[project]
name = "mypackage"
version = "1.0.0"
dependencies = ["httpx"]
[project.optional-dependencies]
cli = ["rich"]
[dependency-groups]
dev = ["typing-extensions"]
[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"
```
will get 4 nodes with the following edges (Version and Source omitted
here for brevity):
* `mypackage`
* `httpx`
* `mypackage(build)`
* `hatchling`
* `mypackage[cli]`
* `mypackage`
* `rich`
* `mypackage:dev`
* `typing-extensions`
Note that `mypackage[cli]` has a dependency edge on `mypackage` while
`mypackage:dev` does not. This is because
`mypackage[cli]` is fundamentally an augmentation of `mypackage` while
`mypackage:dev` is just a list of packages that happens to be defined by
`mypackage`'s pyproject.toml.
The resulting nodes for `mypackage` will look something like:
<details>
<summary>json blob</summary>
```json
{
"resolve": {
"mypackage==1.0.0 @ editable+.": {
"name": "mypackage",
"version": "1.0.0",
"source": {
"editable": "."
},
"kind": "package",
"dependencies": [
{
"id": "httpx==3.6 @ registry+https://pypi.org/simple"
"marker": "sys_platform == 'linux'"
},
],
"optional_dependencies": [
{
"name": "cli",
"id": "mypackage[cli]==1.0.0 @ editable+."
},
],
"dependency_groups": [
{
"name": "dev",
"id": "mypackage:dev==1.0.0 @ editable+."
}
]
"build_system": {
"build_backend": "hatchling.build",
"id": "mypackage(build)==1.0.0 @ editable+."
}
"sdist": { ... },
"wheels": [ ... ]
},
"mypackage:dev==1.0.0 @ editable+.": {
"name": "mypackage",
"version": "1.0.0",
"source": {
"editable": "."
},
"kind": {
"group": "dev"
},
"dependencies": [
{
"id": "typing-extensions==1.2.3 @ registry+https://pypi.org/simple"
},
]
},
}
"mypackage[cli]==1.0.0 @ editable+.": {
"name": "mypackage",
"version": "1.0.0",
"source": {
"editable": "."
},
"kind": {
"extra": "cli"
},
"dependencies": [
{
"id": "rich==2.2.3 @ registry+https://pypi.org/simple"
},
{
"id": "mypackage==1.0.0 @ editable+."
},
]
},
"mypackage(build)==1.0.0 @ editable+.": {
"name": "mypackage",
"version": "1.0.0",
"source": {
"editable": "."
},
"kind": "build",
"dependencies": [
{
"id": "hatchling==3.2.3 @ registry+https://pypi.org/simple"
},
]
}
}
}
```
</details>
## Test Plan
Snapshots
## Summary
- replace the current `FLASH_ATTENTION_SKIP_CUDA_BUILD` wording with a
more accurate description
- explain that the variable disables local CUDA compilation instead of
guaranteeing a compatible wheel
- recommend pinning to a known-supported combination when relying on
published wheels
Addresses #17794.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
Aria Desires