`--paths-to-mutate` support?

[przybylop]

mutmut 2.x. had --paths-to-mutate argument support:

mutmut/mutmut/__main__.py

Lines 317 to 318 in bdd8c37

	if paths_to_mutate is None:
	paths_to_mutate = guess_paths_to_mutate()

whereas it was removed in mutmut 3.x:

mutmut/mutmut/__main__.py

Lines 150 to 151 in e8e0960

	def walk_all_files():
	paths = [guess_paths_to_mutate()]

but README still mentions it:

mutmut/README.rst

Lines 55 to 59 in e8e0960

	.. code-block:: ini
	[mutmut]
	paths_to_mutate=src/
	tests_dir=tests/

and the error message in guess_paths_to_mutate() as well:

mutmut/mutmut/__main__.py

Lines 128 to 131 in e8e0960

	raise FileNotFoundError(
	'Could not figure out where the code to mutate is. '
	'Please specify it on the command line using --paths-to-mutate, '
	'or by adding "paths_to_mutate=code_dir" in setup.cfg to the [mutmut] section.')

is the argument going to be reintroduced?

[boxed]

No. Arguments for conf was a mistake I think. All the conf should always go into the conf file.

Thanks for the heads up on the docs issue. I will fix that.

[przybylop]

Thanks for the quick response!

What about the paths_to_mutate argument from config file? mutmut 3.x ignores it as well

[boxed]

Oh. Well that is a mistake then. It should make good guesses, but when it fails it should read that.

[awgymer]

It should make good guesses, but when it fails it should read that.

Would it not make more sense for it to short-circuit to the conf value if it's set, rather than fall back to it. If it's only used as a fallback it means you can't ever run mutmut in a repo which had e.g. a src folder which did not contain the paths to mutate

[boxed]

Sorry, yea I was sloppy with my language. The conf should override for sure.

[jhovell]

https://github.com/boxed/mutmut/blame/e8e0960f45b3675ff775e2d3580956422d5698ea/mutmut/__main__.py#L113C5-L131C89

^ seems like a serious bug? It's not possible to specify paths-to-mutate by any means, and the guesser function will look only in lib, src or a directory that looks similar to the directory you're in. e.g. my source for a project in the directory called my_project must be in sub directory my_project/myproject or another underscore/dash variant. Otherwise there's no way to get the plugin to run.

[boxed]

Yea, that's a mistake clearly. I've pushed a fix for this on the main branch. If someone affected by this issue could try it out before I make a release that would be appreciated.

[boxed]

This is now shipped in the latest version.

[Julien-Delavisse]

Hello,

Tools like pytest, coverage, etc., allow you to filter the files to be analyzed using markers or glob patterns.
Mutmut no longer offers this option.
I imagine there are good technical reasons for this, but I find it very cumbersome.
Test mutations take a long time and aren’t always relevant depending on the part of the codebase, and I’d really like to be able to pass a glob as a parameter to select the files to mutate.
Right now, I'm looking into the possibility of creating a wrapper around mutmut to rewrite the pyproject.toml file to achieve my goal. But it's a pretty messy solution :(

Am I the only one who feels this way? :D

[Otto-AA]

Hi @Julien-Delavisse . paths_to_mutate is probably not what you expect it to be ( #414 ). It's intended to be directory of your source code, so mutmut knows which code it needs to copy to execute your tests afterwards. It's not intended for selecting which files are mutated.

Mutmut currently supports wildcards that filter the mutations: mutmut run "my_module.my_function*". There's a "Wildcards for testing mutants" section in the docs. Is this what you need?