11 commits

Author	SHA1	Message	Date
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

Renamed from docs/configuration/build-backend.md (Browse further)