astral-sh / uv

An extremely fast Python package and project manager, written in Rust.
https://docs.astral.sh/uv
Apache License 2.0
26.31k stars 767 forks source link

Clarify or amend output of `--no-package`? #8311

Open astrojuanlu opened 4 weeks ago

astrojuanlu commented 4 weeks ago

The documentation of the --no-package flag of uv init says

https://github.com/astral-sh/uv/blob/3fd69b448e27841f7d003d79aab4e31c7995c242/crates/uv-cli/src/lib.rs#L2483

however, uv init --no-package does put a [project] table in pyproject.toml, and in the absence of a [build-system] table, PEP 517 mandates a fallback build backend (setuptools.build_meta:__legacy__).

In summary, it's not entirely clear how not adding a [build-system] table is consistent with the promise of uv init --no-package of "not set up the project to be built as a Python package"?

(Comes from https://discuss.python.org/t/pep-735-dependency-groups-in-pyproject-toml/39233/351)

charliermarsh commented 4 weeks ago

Yeah, that's all correct. The project is still formally "a package" but we don't treat it as such when you run uv-specific commands like uv sync (i.e., we don't build or install it). You can mark it as a package with package = true under [tool.uv].

charliermarsh commented 4 weeks ago

I think the very presence of a pyproject.toml effectively means that a project is "a package" -- you don't even need to have a [project] table, since omitting it means that "The lack of a [project] table implicitly means the build backend will dynamically provide all keys". So the rest is just convention for how tools behave in the presence of such files.

zanieb commented 4 weeks ago

Yeah this is a complicated decision we made. We wanted to be able to use the [project] table for dependencies in workspaces, even if the project itself was not intended to be packaged. As far as I understand, this isn't quite a specification violation since PEP 517 says:

If the pyproject.toml file is absent, or the build-backend key is missing, the source tree is not using this specification, and tools should revert to the legacy behaviour of running setup.py (either directly, or by implicitly invoking the setuptools.build_meta:__legacy__ backend).

Note this isn't a "MUST", and furthermore, we're not really acting as a build frontend in this context — we're acting as a project management tool. In contrast, when installing source trees from elsewhere, we are acting as a build frontend and follow the specification.

The --no-package option is intended as a direction to uv. Are you running into problems with this with other tools?

zanieb commented 4 weeks ago

It's possible we'll be able to do something else now that PEP 735 is accepted, but I'm not sure.

charliermarsh commented 4 weeks ago

Thanks @zanieb for giving a better answer than me.

astrojuanlu commented 4 weeks ago

Thanks for the prompt reply as always 🙏🏼

Are you running into problems with this with other tools?

No, or at least not yet. More than anything I'm trying to get a precise understanding of the terminology and the different moving parts so that I can teach this effectively.

zanieb commented 4 weeks ago

We still have some room to improve our documentation around this. It was a relatively late change. I'll try to remember to respond here when I change things!