--exclude negates the target path

[robin-zealrobotics]

# Correct: lints all files in src
ament_cpplint src 

# Bug: lints all files in current directory (possibly still excluding some things, I didn't verify that)
ament_cpplint --exclude "some/path.cpp" src

# Correct: workaround that does lint all files in src, excluding the path
ament_cpplint --exclude "some/path.cpp" -- src

I assume the way argparse is used to define 'exclude' is defaulting the 'paths' to '.'
I wouldn't be surprised if similar problems exist for other linters.

Only tested this on Iron.

[MichaelOrlov]

Hi, @robin-zealrobotics. That is not a bug, but rather a specific of the Python's args parser and how it parsers positional arguments.
There is no way to distinguish positional argument in this concrete case src from the list entity if it goes right after the explicit list entity. The known workaround is only, as you mentioned, to put the -- separator before the positional argument.

To mitigate this issue, the explicit "paths" argument could be added in addition to the existent positional "paths" argument defined here

ament_lint/ament_cpplint/ament_cpplint/main.py

Lines 88 to 96 in 2e54ed3

	parser.add_argument(
	'paths',
	nargs='*',
	default=[os.curdir],
	help='The files or directories to check. For directories files ending '
	'in %s will be considered.' %
	', '.join(["'.%s'" % e for e in extensions + headers]))
	# not using a file handle directly
	# in order to prevent leaving an empty file when something fails early

We can't just simply change the positional argument "paths" to be a non-explicit argument since it will break backward compatibility.
Also, the documentation could be updated to point out that a workaround with a -- separator should be used when a positional argument needs to be used after the list.
However, help is needed with all of these proposals to be implemented.