astral-sh / uv

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

`uv sync --no-install-package` without pyproject.toml #6722

Open sbidoul opened 2 weeks ago

sbidoul commented 2 weeks ago

On the same theme as #6685 and #6573, but easier to solve?

Since the package name is provided on the CLI and also present in uv.lock, there should be no need to read pyproject.toml at all?

charliermarsh commented 2 weeks ago

Since the package name is provided on the CLI...

Do you mean, if you use uv sync --package?

zanieb commented 2 weeks ago

Similar to #6573, part of the complexity is that we use the pyproject.toml to determine the root directory of the workspace. We'd need to use the uv.lock to encode this instead, just in this case?

zanieb commented 2 weeks ago

I think the thought is --no-install-package my-root-package (or any other package)

charliermarsh commented 2 weeks ago

Ohh I see. I think I'd rather that we put the workspace root in uv.lock, and then allow uv sync or uv sync --package.

charliermarsh commented 2 weeks ago

Honestly it would be easy to support uv sync --package, and users could pass the workspace root, but I know that's a little tedious.

sbidoul commented 2 weeks ago

To clarify, my use case is still the dependencies-only layer of a Dockerfile. It sill itches me a little bit to have to copy pyproject.toml in addition to uv.lock.

uv sync --no-install-package my-root-package --frozen seemed quite close to it: as you mentioned in https://github.com/astral-sh/uv/issues/6573#issuecomment-2308381467 that pyproject.toml is used only to obtain the package name, I assumed it was not necessary since in the case of --no-install-package, the package name is known upfront from the CLI.

charliermarsh commented 2 weeks ago

Yeah it bothers me too. I think we can fix it holistically.

charliermarsh commented 2 weeks ago

I guess one challenging case is: you're workspace is rooted at root, and you're at root/packages/foo. Normally, if you ran uv sync, we'd sync foo. But if we don't have any pyproject.toml etc., we have no way of knowing that you're in that workspace member. So uv sync --frozen would have to sync the workspace root instead.

charliermarsh commented 2 weeks ago

The other strange piece is that you lose any configuration defined in pyproject.toml. (Just documenting things I notice as I work on this.)

sbidoul commented 2 weeks ago

Ah, and extras may also influence the design. What if, for instance, I want to seed the dependencies of my root package but only some of it's optional dependencies?

zanieb commented 2 weeks ago

@charliermarsh that seems particularly problematic :/ we don't really want to copy all those into the lock do we?

charliermarsh commented 2 weeks ago

Ah, and extras may also influence the design. What if, for instance, I want to seed the dependencies of my root package but only some of it's optional dependencies?

This would work as expected, I think, since we store this information in the lock.

that seems particularly problematic :/ we don't really want to copy all those into the lock do we?

No, I don't think so. The situation we're at now is we still require the root pyproject.toml but none of the members (as of my PR last night).

I think we can support not requiring the pyproject.toml at all, but users would need to copy it over if they had configuration defined in there.