Copy lockfile (`uv.lock`/`poetry.lock`/…) alongside `pyproject.toml` into the mutants tree

[ejfine]

Summary

mutmut auto-copies pyproject.toml (plus tests/, setup.cfg, test*.py) into the mutants/ tree, but not the adjacent lockfile. When a project's type_check_command or test command uses a resolver wrapper (uv run …, poetry run …), that subprocess runs in the mutants/ cwd, finds the copied pyproject.toml with no lock beside it, and re-resolves dependencies from the version constraints. The resulting mutants/.venv can differ from the project's locked/installed environment, silently breaking type-checking or tests inside mutmut.

mutmut already copies the dependency spec (pyproject.toml); copying the matching resolution (the lockfile) is the natural completeness fix. Adding also_copy = ["uv.lock"] works around it today, confirming the missing lockfile is the cause.

Scope: affects projects that resolve deps via uv/poetry and wrap their type-check/test command in uv run/poetry run. Projects using a bare command inherit the active environment and are unaffected.

Why wrap the command in uv run at all?

For a project packaged as an installable distribution (e.g. [tool.uv] package = true) whose code imports itself by package name (from mypkg import …), the type checker must resolve mypkg to the mutant copy under mutants/src, not the original source. uv run executed in the mutants/ cwd reinstalls the project editable against the mutant tree, giving the checker one consistent copy.

A bare pyrefly check instead inherits the parent environment, where mypkg is editable-installed pointing at the original src/. The checker then sees two copies of every class — the originals (via the installed package) and the mutants (the files under check) — and reports spurious "X is not assignable to Y" errors across the two trees, on non-mutant lines, which aborts mutmut. So uv run/poetry run is the correct command for installed-package projects; it is not gratuitous. (Projects that merely put src/ on the path have no editable install to conflict, so the bare command shown in the docs works for them.)

Root cause

mutmut/configuration.py (~line 125) hardcodes the copy list with pyproject.toml but no lockfile:

also_copy=[Path(y) for y in s("also_copy", [])]
+ [
    Path("tests/"),
    Path("test/"),
    Path("setup.cfg"),
    Path("pyproject.toml"),
]
+ list(Path(".").glob("test*.py")),

Suggested fix

Add lockfiles to the same hardcoded list — missing ones are already skipped by the existence check in copy_also_copy_files, exactly like setup.cfg:

also_copy=[Path(y) for y in s("also_copy", [])]
+ [
    Path("tests/"),
    Path("test/"),
    Path("setup.cfg"),
    Path("pyproject.toml"),
    Path("uv.lock"),
    Path("poetry.lock"),
    Path("Pipfile.lock"),
    Path("pdm.lock"),
]
+ list(Path(".").glob("test*.py")),

Copying only when present (the existing copy_also_copy_files guard) means no behavior change for projects without a lockfile.

Environment

• mutmut 3.6.0
• Python 3.13

[Otto-AA]

Makes sense, feel free to make a PR with this.

In general, I think we should move to copying all git-tracked files per default. Making a hard-coded list will always miss some cases.

[ejfine]

move to copying all git-tracked files per default

just using subprocess to call out to git and assuming that if someone is using mutmut then they should have git available on their PATH ? Alternative would be using something like dulwich that's pure python, but it seems reasonable (to me) to assume git should just be available on PATH

[ejfine]

and still leave the also_copy in case someone needs to bring in something from a folder higher up (e.g. a lock file for the whole workspace in a monorepo that sits in the directory above where mutmut is being run)? would the default just be to place any ../foo.txt files in the mutants root? or do you think we'd need to turn it into tuple of [src, dest]?

and then maybe add an exclude_from_copy field if someone has some big giant binary files for some reason (or some other situation we can't think of right now) that they don't want to waste time copying?

[ejfine]

hmm, thinking on it, copying everything tracked by git opens a bit of a larger set of questions. what do you think about a PR now just to add those lock files, and then maybe gathering more thoughts/opinions from the community for a future PR on the best way to go about utilizing git to copy most things?

[nicklafleur]

that seems very reasonable to me.

[ejfine]

@nicklafleur - here's a PR for it #534

[Otto-AA]

just using subprocess to call out to git and assuming that if someone is using mutmut then they should have git available on their PATH ? Alternative would be using something like dulwich that's pure python, but it seems reasonable (to me) to assume git should just be available on PATH

I'd use subprocess, we already use the CLI git (if available) for tracking which files changed:

mutmut/src/mutmut/__main__.py

Line 880 in 523a19c

def _run_git(args: list[str]) -> str | None:

I think if we encounter too much complexity by parsing stdout output, we should consider to use dulwich/gitpython/pygit2 instead.

and still leave the also_copy in case someone needs to bring in something from a folder higher up (e.g. a lock file for the whole workspace in a monorepo that sits in the directory above where mutmut is being run)?

Yes, I would keep also_copy. I think mainly to copy .gitignored files if they are relevant.

would the default just be to place any ../foo.txt files in the mutants root? or do you think we'd need to turn it into tuple of [src, dest]?

I guess whatever we currently do should be good. I don't think anyone ever created a GH issue about this, so the current implementation likely covers the relevant cases.

and then maybe add an exclude_from_copy field if someone has some big giant binary files for some reason (or some other situation we can't think of right now) that they don't want to waste time copying?

Yes, maybe do_not_copy so it's more similarly named to do_not_mutate?