I’ve just upgraded to pants 2.16 and think I’ve found some issues: 1. the ruff rule INP001 (implicit-namespace-package, i.e. find’s missing

__init__.py

files) fails when running ruff through pants but not when running manually. I suspect this is to do with how pants splits up files to be linted in batches instead of all together. This isn’t a big deal but thought I’d highlight it as an issue with the ruff integration. 2. Test coverage no longer works, it fails with the following error. This is pretty annoying as we now can’t generate test coverage for our application

ERROR: usage: pex [options] [file_or_dir] [file_or_dir] [...]
pex: error: unrecognized arguments: --cov-report= --cov-config=.coveragerc --cov=src/python --cov=test/python
  inifile: None
  rootdir: /private/var/folders/vt/dcxqbnwx731dttw2b1ngmsc00000gn/T/pants-sandbox-pkH6WR

3. When defining visibility rules, the docs state that

python_sources

can be used as a target unquoted, I didn’t find this to be true, it fails with the following error, putting it in quotes works though:

Engine traceback:
  in `dependencies` goal
  in Find targets from input specs

MappingError: Failed to parse ./src/python/platform_cli/BUILD:
TypeError: decoding to str: need a bytes-like object, Registrar found

4. It wasn’t clear from your docs on how to define visibility rules for 3rd party dependencies and the way it is defined in the examples in your docs and blog post didn’t seem to work. In the end I figured out, after some trial and error, that

"//3rdparty/python**"

worked as a catch all for any 3rd party dependencies. The format

"//3rdparty/python:pipenv#xxx"

didn’t work for me (neither did many other combinations of path and wildcards). 5. Pyright doesn’t always seem to give the same errors as VSCode does (i.e. using pyright under the hood), I don’t have specific examples right now but it doesn’t always seem to be consistent. I want to shout out the great work though, the ruff integration is great and I think being able to define visibility rules will be super useful as our application grows. Let me know if you want any more information on any of these issues and/or you want me to raise them as GitHub issues.

Re #2 - do you have a custom lockfile for pytest?

I have the following in my pants.toml

[pytest]
install_from_resolve = "python-default"
execution_slot_var = "EXECUTION_SLOT"

Adding pytest-cov to my 3rd party requirements has resolved this issue. Thanks for the prompt, still getting my head around the new

install_from_resolves

option

Re #2:

[pytest]
install_from_resolve = "python-default"
requirements =[
    "//:requirements#pytest",
    "//:requirements#pytest-cov",
]

This was my

requirements

to get coverage working (change to your requirements location). Your

python-default

resolve will need to provide those.

Can you file an issue for #1?

Thanks @billions-keyboard-33102, I’ve resolved number two by adding pytest-cov to the python-default requirements, there was no need to add the requirements array in the pants.toml file @bitter-ability-32190 Issue up https://github.com/pantsbuild/pants/issues/19364

Yeah, without

requirements=

your tests will use the entire lockfile (which is fine if it's a dedicated lockfile for pytest, but probably not what you want if you're using python-default, because it means your tests will all be invalidated if any requirement in that lockfile changes)

That’s great, thanks for the explanation, I’ve added in those requirement, also seems to speed up the build of the pytest runner (presumably because it’s only installing a small subset of the packages in my lcokfile now)