Soliciting your opinions about the

No applicable files or targets matched.

WARN log: Today when you do things like

./pants test ::

or

./pants --changed-since=main --changed-dependees=transitive test

and no test files match, you get a WARN log along the lines of

17:18:14.39 [WARN] No applicable files or targets matched. The `test` goal works with these target types:

  * go_package
  * junit_test
  * python_test
  * scala_junit_test
  * scalatest_test
  * shunit2_test

However, you only specified targets with these target types:

  * python_source

Please specify relevant files and/or targets. Run `./pants filter --target-type=go_package,junit_test,python_test,scala_junit_test,scalatest_test,shunit2_test ::` to find all applicable targets in your project, or run `./pants filter --target-type=go_package,junit_test,python_test,scala_junit_test,scalatest_test,shunit2_test :: | xargs ./pants filedeps` to find all applicable files.

I am currently wondering whether this warning is desirable. • Arguments for it include that it may help catch cases where your Pants command did not match your intent. • Arguments against it include that the empty set is not a special case, so if "run all tests that match this spec" ends up being fulfilled vacuously then so be it. This is particularly salient for

--changed-*

or when generating command specs from other data.

I'm +1 to remove. Although

./pants --change-since=upstream/main fmt lint check test

works, I have to

2>/dev/null

to avoid being nannied.

1️⃣ if you give me an option that disables it easily. I suppose I can add to pants warnings filter, but that's clunky Otherwise 2️⃣

Proliferation of options and all that, but at some point it make make sense to provide more structure to our warnings and suggestions and then have a global flag

--player-level={beginner,tradesman,aggro}

~paraphrasing.

It'd be an advanced option, as it's only useful to warn for users IMO

To accomodate a growing number of features and use cases, so will options also multiply. Of course all new options should be motivated, but what I think is important is to be able to group/search/filter them logically to be manageable.

It might be some set of options are only really relevant for CI. In that case Pants might benefit from a --ci flag, not different fr a grabag option like --strict for mypy

https://github.com/pantsbuild/pants/pull/14904 - proposed PR to remove this WARNing

@bitter-ability-32190 I don’t repo your unknown goal issue. Could you have custom

.pants.rc

files in

$HOME

or

.

that trips up your configuration?

$ ./pants ignore-no-targets-warning test
$ ./pants test ignore-no-targets-warning
Unknown flag --ignore-warnings on test scope
Did you mean to use the global --ignore-warnings? Global options must come before any goals, or after any file/target arguments.
[...]

I suspect it might be due to also using a flag in conjunction. Try it with

-ldebug

as well

Nope, works fine with

-ldebug

for me too…