Skip to content

Conversation

@danielgafni
Copy link
Contributor

@danielgafni danielgafni commented Oct 24, 2024

Summary

uv sync CLI command now respects UV_SYNC_ALL_EXTRAS environment variable.


Is can also add a config option if you think it makes sense to have one.

@zanieb zanieb requested a review from charliermarsh October 24, 2024 20:21
@danielgafni danielgafni force-pushed the sync-all-extras-config branch from f4e7d27 to a5c3215 Compare October 24, 2024 20:24
@zanieb
Copy link
Member

zanieb commented Oct 30, 2024

Just wondering, what's the use-case for this?

@danielgafni
Copy link
Contributor Author

danielgafni commented Oct 30, 2024

Multiple uv sync invocations in a single Dockerfile

@zanieb
Copy link
Member

zanieb commented Oct 30, 2024

Why are you making multiple invocations where --all-extras matters? Just trying to understand the use-case because this isn't the kind of thing we've been exposing as an environment variable.

@danielgafni
Copy link
Contributor Author

danielgafni commented Oct 30, 2024

I don't think the use cases are super solid. It's more like a nice to have feature.

Imo ideally all CLI arguments should have corresponding env variables. Is your opinion different or you are just looking for clarification?

This just make usage easier in some (probably rare) cases: doing multiple invocations with other arguments varying in docker/CI, controlling this behavior in CI pipelines without changing the CLI command (CI pipelines often pass env variables to each other), setting a development default for a project (what actually made me start this PR).

The latter should really be a config parameter tho, but as a Rust newbee I decided to start from something more straightforward like an env variable.

@zanieb
Copy link
Member

zanieb commented Oct 30, 2024

Imo ideally all CLI arguments should have corresponding env variables. Is your opinion different or you are just looking for clarification?

I think this is actually against our philosophy. I don't think every CLI argument should have a corresponding variable — only ones that configure something you'd commonly want to set as persistent state.

It sounds more like your use-case here would be solved by a default-extras setting.

@danielgafni
Copy link
Contributor Author

Understood, let me know if you still want this PR

@konstin
Copy link
Member

konstin commented Apr 28, 2025

Would this be covered by #12965?

@danielgafni
Copy link
Contributor Author

I don't think so --- originally I needed this when building a docker image for a uv workspace with multiple internal extras. So I didn't want this to be a part of the global config, but rather a one time settings just for the docker image.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants