Commit Graph

38 Commits

Author SHA1 Message Date
Zanie Blue 7789f5b217
Bump version to 0.8.17 (#15776) 2025-09-10 14:59:48 -05:00
Charlie Marsh 2de677b0d3
Bump version to v0.8.16 (#15761)
Co-authored-by: Zanie Blue <contact@zanie.dev>
2025-09-09 21:41:56 -04:00
Charlie Marsh 70cb0df7c2
Bump version to v0.8.15 (#15648) 2025-09-03 02:10:58 +00:00
Anthony Wu 5f0ec6805a
Fix simple typo for python that ends in -m (#15624)
## Summary

Fix simple doc typo `s/pythom/python`

## Test Plan

Doc string update, proposing accept as-is.
2025-09-01 21:43:48 -04:00
Zanie Blue af856fb883
Bump version to 0.8.14 (#15576) 2025-08-28 21:25:02 +00:00
konsti db4dfb4cf9
Add logging to the uv build backend (#15533)
Add support for `RUST_LOG` to the uv build backend. While we were
previously using logging statements in the uv build backend, they could
only be shown when when using the direct build fast path through uv, as
there was no tracing subscriber to write log messages out. This means no
debug logging when using the build backend through pip, `python -m
build`, an incompatible version of uv, or any other build frontend; No
option to figure why includes and excludes behave the way they do.

This PR closes this gap by adding a tracing subscriber. The only option
to enable it is `RUST_LOG`, as we don't have a CLI. The formatting style
is the same as for uv, and color is also support in the same way, albeit
only through anstream's support for TTYs and environment variables. We
recommend only `RUST_LOG=uv=debug` and `RUST_LOG=uv=verbose` in the
docs, but this can be used to debug into crates such as `glob`, too.

<img width="1008" height="325" alt="image"
src="https://github.com/user-attachments/assets/d33df219-750b-46a2-b3b4-8895aa137ab9"
/>

**Before**

```
$ pip wheel . -v [...]
Looking in links: /home/konsti/projects/uv/target/wheels/
Processing /home/konsti/projects/uv/scripts/packages/built-by-uv
  Running command pip subprocess to install build dependencies
  Looking in links: /home/konsti/projects/uv/target/wheels/
  Processing /home/konsti/projects/uv/target/wheels/uv_build-0.8.13-py3-none-manylinux_2_39_x86_64.whl
  Installing collected packages: uv_build
  Successfully installed uv_build-0.8.13
  Installing build dependencies ... done
  Running command Getting requirements to build wheel
  Getting requirements to build wheel ... done
  Running command Preparing metadata (pyproject.toml)
  Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: built-by-uv
  Running command Building wheel for built-by-uv (pyproject.toml)
  Error: Unsupported glob expression in: `tool.uv.build-backend.*-exclude`

  Caused by:
      Invalid character `!` at position 10 in glob: `**/build-*!$§%!½¼²¼³¬!§%$§%.h`. hint: Characters can be escaped with a backslash
  error: subprocess-exited-with-error

  × Building wheel for built-by-uv (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> See above for output.

  note: This error originates from a subprocess, and is likely not a problem with pip.
  full command: /usr/bin/python3 /usr/lib/python3/dist-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py build_wheel /tmp/tmpow1illc9
  cwd: /home/konsti/projects/uv/scripts/packages/built-by-uv
  Building wheel for built-by-uv (pyproject.toml) ... error
  ERROR: Failed building wheel for built-by-uv
Failed to build built-by-uv
ERROR: Failed to build one or more wheels
```

**After**

```
$ RUST_LOG=uv=debug pip wheel . -v [...]
Looking in links: /home/konsti/projects/uv/target/wheels/
Processing /home/konsti/projects/uv/scripts/packages/built-by-uv
  Running command pip subprocess to install build dependencies
  Looking in links: /home/konsti/projects/uv/target/wheels/
  Processing /home/konsti/projects/uv/target/wheels/uv_build-0.8.13-py3-none-manylinux_2_39_x86_64.whl
  Installing collected packages: uv_build
  Successfully installed uv_build-0.8.13
  Installing build dependencies ... done
  Running command Getting requirements to build wheel
  Getting requirements to build wheel ... done
  Running command Preparing metadata (pyproject.toml)
  DEBUG Writing metadata files to /tmp/pip-modern-metadata-l_kh78cj
  DEBUG Found PEP 639 license declarations, using METADATA 2.4
  DEBUG License files match: `LICENSE-APACHE`
  DEBUG License files match: `LICENSE-MIT`
  DEBUG License files match: `third-party-licenses/PEP-401.txt`
  Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: built-by-uv
  Running command Building wheel for built-by-uv (pyproject.toml)
  DEBUG Checking metadata directory /tmp/pip-modern-metadata-l_kh78cj/built_by_uv-0.1.0.dist-info
  DEBUG Found PEP 639 license declarations, using METADATA 2.4
  DEBUG License files match: `LICENSE-APACHE`
  DEBUG License files match: `LICENSE-MIT`
  DEBUG License files match: `third-party-licenses/PEP-401.txt`
  DEBUG Writing wheel at /tmp/pip-wheel-bu6to9i7/built_by_uv-0.1.0-py3-none-any.whl
  DEBUG Wheel excludes: ["__pycache__", "*.pyc", "*.pyo", "build-*!$§%!½¼²¼³¬!§%$§%.h", "/src/built_by_uv/not-packaged.txt"]
  Error: Unsupported glob expression in: `tool.uv.build-backend.*-exclude`

  Caused by:
      Invalid character `!` at position 10 in glob: `**/build-*!$§%!½¼²¼³¬!§%$§%.h`. hint: Characters can be escaped with a backslash
  error: subprocess-exited-with-error

  × Building wheel for built-by-uv (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> See above for output.

  note: This error originates from a subprocess, and is likely not a problem with pip.
  full command: /usr/bin/python3 /usr/lib/python3/dist-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py build_wheel /tmp/tmpjrxou13a
  cwd: /home/konsti/projects/uv/scripts/packages/built-by-uv
  Building wheel for built-by-uv (pyproject.toml) ... error
  ERROR: Failed building wheel for built-by-uv
Failed to build built-by-uv
ERROR: Failed to build one or more wheels
```

(There is no color in the above uv log statements, as pip doesn't
register as a TTY)

Fixes #12723
2025-08-27 09:14:00 +02:00
Zanie Blue ede75fe628
Bump version to 0.8.13 (#15423) 2025-08-21 13:52:39 -05:00
Zanie Blue f784c334cf
Bump version to 0.8.12 (#15364) 2025-08-18 22:14:51 +00:00
Zanie Blue f892276ac8
Bump version to 0.8.11 (#15287) 2025-08-14 14:21:10 -05:00
Zanie Blue 7e817bafde
Bump version to 0.8.10 (#15257) 2025-08-13 20:06:08 +00:00
Zanie Blue 68c0bf8a2c
Bump version to 0.8.9 (#15229) 2025-08-11 21:07:59 -05:00
Zanie Blue 9a54754b0a
Bump version to 0.8.8 (#15184) 2025-08-08 19:03:07 -05:00
Zanie Blue 8a22572338
Bump version to 0.8.7 (#15173) 2025-08-08 14:42:23 -05:00
Charlie Marsh 329a6b446a
Bump version to v0.8.6 (#15137) 2025-08-07 16:17:14 +01:00
Zanie Blue ce37286814
Bump version to 0.8.5 (#15093) 2025-08-05 20:21:00 +00:00
Zanie Blue e176e17144
Bump version to 0.8.4 (#14980) 2025-07-30 16:24:20 +00:00
Zanie Blue 7e78f54e7c
Bump version to 0.8.3 (#14875) 2025-07-24 15:51:15 -05:00
Zanie Blue 21fadbcc13
Bump version to 0.8.2 (#14832) 2025-07-22 19:39:53 +00:00
Zanie Blue f0151f3a18
Bump version to 0.8.1 (#14818) 2025-07-22 11:36:20 -05:00
Zanie Blue 1a339b76e8 Add release notes and bump version for 0.8.0 (#14690)
[Rendered](https://github.com/astral-sh/uv/blob/zb/release-notes/CHANGELOG.md)
2025-07-17 17:20:21 -05:00
konsti 3c9aea87b4 `uv init`: Make `uv_build` the default build backend (from `hatchling`) (#14661)
Closes https://github.com/astral-sh/uv/issues/14298

Switch the default build backend for `uv init` from `hatchling` to
`uv_build`.

This change affects the following two commands:

* `uv init --lib`
* `uv init [--app] --package`

It does not affect `uv init` or `uv init --app` without `--package`. `uv
init --build-backend <...>` also works as before.

**Before**

```
$ uv init --lib project
$ cat project/pyproject.toml
[project]
name = "project"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
authors = [
    { name = "konstin", email = "konstin@mailbox.org" }
]
requires-python = ">=3.13.2"
dependencies = []

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"
```

**After**

```
$ uv init --lib project
$ cat project/pyproject.toml
[project]
name = "project"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
authors = [
    { name = "konstin", email = "konstin@mailbox.org" }
]
requires-python = ">=3.13.2"
dependencies = []

[build-system]
requires = ["uv_build>=0.7.20,<0.8"]
build-backend = "uv_build"
```

I cleaned up some tests for consistency in the second commit.
2025-07-17 17:20:21 -05:00
Zanie Blue 78d6d1134a
Bump version to 0.7.22 (#14685) 2025-07-17 11:27:15 -05:00
Geoffrey Thomas 77c771c7f3
Bump version to 0.7.21 (#14611) 2025-07-14 14:01:28 -04:00
konsti e798b09aa4
Multiple modules in namespace packages (#14460)
Support multiple root modules in namespace packages by enumerating them:

```toml
[tool.uv.build-backend]
module-name = ["foo", "bar"]
```

This allows applications with multiple root packages without migrating
to workspaces. Since those are regular module names (we iterate over
them an process each one like a single module names), it allows
combining dotted (namespace) names and regular names. It also
technically allows combining regular and stub modules, even though this
is even less recommends.

We don't recommend this structure (please use a workspace instead, or
structure everything in one root module), but it reduces the number of
cases that need `namespace = true`.

Fixes #14435
Fixes #14438

---------

Co-authored-by: Zanie Blue <contact@zanie.dev>
2025-07-09 17:45:44 +00:00
Zanie Blue 812a3e7c34
Bump version to 0.7.20 (#14525) 2025-07-09 12:15:41 -05:00
Zanie Blue 38ee6ec800
Bump version to 0.7.19 (#14431) 2025-07-02 21:19:52 +00:00
konsti 71b5ba13d7
Stabilize the uv build backend (#14311)
The uv build backend has gone through some feedback cycles, we expect no
more major configuration changes, and we're ready to take the next step:
The uv build backend in stable.

This PR stabilizes:

* Using `uv_build` as build backend
* The documentation of the uv build backend
* The direct build fast path, where uv doesn't use PEP 517 if you're
using `uv_build` in a compatible version.
* `uv build --list`, which is limited to `uv_build`.

It does not:
* Make `uv_build` the default on `uv init`
* Make `--package` the default on `uv init`
2025-07-02 15:37:43 -05:00
konsti a7aa46acc5
Add a "choosing a build backend" section to the docs (#14295)
I think the build backend docs as a whole are now ready for review. I
only made a small change here.

---------

Co-authored-by: Zanie Blue <contact@zanie.dev>
2025-07-02 09:02:03 -05:00
Zanie Blue 87e9ccfb92
Bump version to 0.7.18 (#14402) 2025-07-01 15:30:44 -05:00
Zanie Blue b1812d111a
Edits to the build backend documentation (#14376)
Co-authored-by: konstin <konstin@mailbox.org>
2025-07-01 08:44:23 +00:00
Charlie Marsh 41c218a89b
Bump version to 0.7.17 (#14347) 2025-06-29 09:58:33 -04:00
Zanie Blue b6b7409d13
Bump version to 0.7.16 (#14334) 2025-06-27 16:46:36 -05:00
John Mumm 4ed9c5791b
Bump version to 0.7.15 (#14254) 2025-06-25 12:06:41 +02:00
Aria Desires 92de53f4eb
Bump version to 0.7.14 (#14218) 2025-06-23 12:48:51 -04:00
Zanie Blue 62ed17b230
Bump version to 0.7.13 (#14002) 2025-06-12 14:33:31 -05:00
konsti 7316bd01a3
Build backend: Support namespace packages (#13833)
Unlike regular packages, specifying all `__init__.py` directories for a
namespace package would be very verbose There is e.g.
https://github.com/python-poetry/poetry/tree/main/src/poetry, which has
18 modules, or https://github.com/googleapis/api-common-protos which is
inconsistently nested. For both the Google Cloud SDK, there are both
packages with a single module and those with complex structures, with
many having multiple modules due to versioning through `<module>_v1`
versioning. The Azure SDK seems to use one module per package (it's not
explicitly documented but seems to follow from the process in
https://azure.github.io/azure-sdk/python_design.html#azure-sdk-distribution-packages
and
ccb0e03a3d/doc/dev/packaging.md).

For simplicity with complex projects, we add a `namespace = true` switch
which disabled checking for an `__init__.py`. We only check that there's
no `<module_root>/<module_name>/__init__.py` and otherwise add the whole
`<module_root>/<module_name>` folder. This comes at the cost of
`namespace = true` effectively creating an opt-out from our usual checks
that allows creating an almost entirely arbitrary package.

For simple projects with only a single module, the module name can be
dotted to point to the target module, so the build still gets checked:

```toml
[tool.uv.build-backend]
module-name = "poetry.core"
```

## Alternatives

### Declare all packages

We could make `module-name` a list and allow or require declaring all
packages:

```toml
[tool.uv.build-backend]
module-name = ["cloud_sdk.service.storage", "cloud_sdk.service.storage_v1", "cloud_sdk.billing.storage"]
```

Or for Poetry:

```toml
[tool.uv.build-backend]
module-name = [
    "poetry.config",
    "poetry.console",
    "poetry.inspection",
    "poetry.installation",
    "poetry.json",
    "poetry.layouts",
    "poetry.masonry",
    "poetry.mixology",
    "poetry.packages",
    "poetry.plugins",
    "poetry.publishing",
    "poetry.puzzle",
    "poetry.pyproject",
    "poetry.repositories",
    "poetry.toml",
    "poetry.utils",
    "poetry.vcs",
    "poetry.version"
]
```

### Support multiple namespaces

We could also allow namespace packages with multiple root level module:

```toml
[tool.uv.build-backend]
module-name = ["cloud_sdk.my_ext", "local_sdk.my_ext"]
```

For lack of use cases, we delegate this to creating a workspace with one
package per module.

## Implementation

Due to the more complex options for the module name, I'm moving
verification on deserialization later, dropping the source span we'd get
from serde. We also don't show similarly named directories anymore.

---------

Co-authored-by: Andrew Gallant <andrew@astral.sh>
2025-06-12 17:23:58 +00:00
Zanie Blue dc3fd46472
Bump version to 0.7.12 (#13892) 2025-06-06 19:42:06 +00:00
Zanie Blue 262ca73965
Remove the configuration section in favor of concepts / reference (#13842)
Extends https://github.com/astral-sh/uv/pull/13841 — I'll drop that
commit later after that pull request merges but it's small.

I find the split into a "Configuration" section awkward and don't think
it's helping us. Everything moved into the "Concepts" section, except
the "Environment variables" page which definitely belongs in the
reference and the "Installer" page which is fairly niche and seems
better in the reference.

Before / After


<img
src="https://github.com/user-attachments/assets/80d8304b-17da-4900-a5f4-c3ccac96fcc5"
width="400">
2025-06-05 17:09:49 +00:00