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

[jensqin]

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]

Can you share more details about "different users"?

[jensqin]

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

[SamyAB]

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]

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

[jsiverskog]

i want this for the sole purpose of keeping my repository roots clean - i prefer to have as many as possible of environment related files in a separate directory.

[vladidobro]

Hi, I would say that support for multiple lockfiles is extremely important for scalable monorepos, and is the last missing piece for us to fully commit to a uv-based monorepo.

For example in our setup of some shared libs + many domain-specific applications with data pipelines, I would like to be able to use a new feature of some library without being forced to upgrade and test it and fix it in all of the other applications (100+ mostly completely unrelated pipelines).

Our current options seem to be

• use pants
• dont use workspaces, treat is as unrelated uv packages that just happen to be in one repo (very inconvenient)

Or is there already a way to achieve it with uv workspaces? Does uv plan some "environments" support for these usecases?

Thank you!

[g0di]

I'm using nox for running tests on my libraries against multiple versions of Python. On my nox test session I'm using the uv --resolution flag to run my tests against highest and lowest versions of required dependencies which is super useful. However, this cause uv to re-lock and override the uv.lock on each session. I would find it useful to tell uv to use separated lock files for both resolution strategies as well as using the default one in day-to-day situations.

[konstin]

@g0di Can you use uv pip install --resolution lowest . for your tests, or do you need a lockfile for lowest, too`

[zanieb]

You can use --isolated for an isolated lockfile.

[g0di]

Those are two interesting options I did not think about. Let me give it a try to see if it fits my needs! Thanks!

[g0di]

You can use --isolated for an isolated lockfile.

I was wondering why I did not see this one but using the latest uv version gives me this:

warning: The `--isolated` flag is deprecated and has no effect. Instead, use `--no-config` to prevent uv from discovering configuration files.

I tried with --isolated and --no-config but it did not work (the first is ignored and the second ignore my whole configuration breaking my builds).

[zanieb]

Sorry, what command are you using? It's available on uv run to use an isolated environment and lockfile.

[g0di]

Sorry, what command are you using? It's available on uv run to use an isolated environment and lockfile.

I was trying to use uv sync because it fits better in my nox file. The idea is that nox creates me a venv, then I sync my project and lowest/highest dependencies in it and finally run my tests. So I end up with one venv per combinations or python version and resolution strategy. Not having the ability to use different locks file cause this to relock everything each time.

@g0di Can you use uv pip install --resolution lowest . for your tests, or do you need a lockfile for lowest, too`

This is what I tried to achieve and ended up with the following nox session, leveraging compile and install. It looks like its working as expected even if its a bit verbose (considering I'll have to copy paste this in all my company projects).

@nox.session(python=["3.9", "3.12"], reuse_venv=True, venv_backend="uv")
@nox.parametrize("resolution", ["lowest-direct", "highest"])
def tests(session: nox.Session, resolution: str) -> None:
    session.run_install(
        "uv",
        "pip",
        "compile",
        "pyproject.toml",
        "--group=dev",
        "--format=pylock.toml",
        f"--resolution={resolution}",
        f"--output-file=pylock.{resolution}.toml",
        external=True,
        silent=True,
    )
    session.install("--no-deps", "--exact", f"-r=pylock.{resolution}.toml")
    session.install(".", "--no-deps")

    session.run("coverage", "run", "--parallel-mode", "-m", "pytest")
    session.notify("coverage")

I'm using uv pip compile because I can use the pylock format and include hashes automatically. Also, I suppose that when I rerun this command, uv reuse the existing lock file reducing the compile time (to be confirmed).

I'm open to feedback!

[NicholasPini]

Just adding my possible use case: I'm building a ci/cd pipeline which needs to build and push docker containers. These containers are used to setup a python environment for an application to eventually run inside. My idea is to use uv lock --check using the uv.lock of the previous commit to check if dependencies have changed: if so, rebuild the container, otherwise I skip this step entirely. Not sure if there's a way to do this right now. My workaround is to rename the current uv.lock to something else, get the previous uv.lock, run uv lock --check and then replace the old file with the file I previously renamed.