Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: add --lockfile flag to allow users to customize lock file name #6830

Open
jensqin opened this issue Aug 29, 2024 · 4 comments
Open
Labels
cli Related to the command line interface needs-decision Undecided if this should be done

Comments

@jensqin
Copy link

jensqin commented Aug 29, 2024

Usecase

When a project needs to have multiple lock files for different users, it is convenient to be able to rename the lockfile.

API Suggestion

uv lock --lockfile my_uv_lock_file.lock

Context

pdm has this feature.

@zanieb
Copy link
Member

zanieb commented Aug 29, 2024

Can you share more details about "different users"?

@zanieb zanieb added needs-decision Undecided if this should be done cli Related to the command line interface labels Aug 29, 2024
@jensqin
Copy link
Author

jensqin commented Aug 30, 2024

I should have said "different resolution". For example, one user wants to use "highest", and another wants to use "lowest-direct".

@SamyAB
Copy link

SamyAB commented Aug 30, 2024

I agree that the feature would be very useful in different situations. In addition to the case that @jensqin mentioned, I personally use the --lockfile option from pdm to have different locks based on different sources. Right now with uv that might be translated as different lockfiles based on different sets of --index-url and --extra-index-url

@nikhilweee
Copy link

Another use case is to support conflicting dependencies if/when #6981 is implemented.

BurntSushi added a commit that referenced this issue Nov 13, 2024
This PR adds support for conflicting extras. For example, consider
some optional dependencies like this:

```toml
[project.optional-dependencies]
project1 = ["numpy==1.26.3"]
project2 = ["numpy==1.26.4"]
```

These dependency specifications are not compatible with one another.
And if you ask uv to lock these, you'll get an unresolvable error.

With this PR, you can now add this to your `pyproject.toml` to get
around this:

```toml
[tool.uv]
conflicting-groups = [
    [
      { package = "project", extra = "project1" },
      { package = "project", extra = "project2" },
    ],
]
```

This will make the universal resolver create additional forks
internally that keep the dependencies from the `project1` and
`project2` extras separate. And we make all of this work by reporting
an error at **install** time if one tries to install with two or more
extras that have been declared as conflicting. (If we didn't do this,
it would be possible to try and install two different versions of the
same package into the same environment.)

This PR does *not* add support for conflicting **groups**, but it is
intended to add support in a follow-up PR.

Closes #6981

Fixes #8024

Ref #6729, Ref #6830

This should also hopefully unblock
dagster-io/dagster#23814, but in my testing, I
did run into other problems (specifically, with `pywin`). But it does
resolve the problem with incompatible dependencies in two different
extras once you declare `test-airflow-1` and `test-airflow-2` as
conflicting for `dagster-airflow`.

NOTE: This PR doesn't make `conflicting-groups` public yet. And in a
follow-up PR, I plan to switch the name to `conflicts` instead of
`conflicting-groups`, since it will be able to accept conflicting extras
_and_ conflicting groups.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cli Related to the command line interface needs-decision Undecided if this should be done
Projects
None yet
Development

No branches or pull requests

4 participants