Since upgrading to 2 14 we re now getting a lot of warnings

Question

Since upgrading to 2 14 we re now getting a lot of warnings about inferring owners of imports Predominantly they re `pytest` Is this a known thing

sparse-lifeguard-95737 · Answer

yes this happens if you import a module that doesn t map to a `python requirement` target possibly one generated by a `python requirements` dependency inference has never worked for these cases but before 2 14 the default behavior was to silently move on 2 14 flipped the default behavior to log warnings for each inference failure

ambitious-actor-36781 · Answer

so I gotta add pytest to my requirements txt and keep it synced with my pytest lockfile

sparse-lifeguard-95737 · Answer

that is one option you could also add a comment to the import lines to disable inference for them the warning messages should include the comment text

ambitious-actor-36781 · Answer

yeah lots of pytest imports

ambitious-actor-36781 · Answer

we ve set the inference option to ignore But seems suboptimal

sparse-lifeguard-95737 · Answer

this hits other subsystems too i e `extra type stubs` in `mypy` aren t seen by the inference rules same for `pylint` if you have any in repo plugins

sparse-lifeguard-95737 · Answer

I will raise with the other maintainers to see if there s a way we could make this UX better

sparse-lifeguard-95737 · Answer

it has personally annoyed me more than once slightly smiling face so I feel your pain

ambitious-actor-36781 · Answer

yeah already had one issue with keeping lockfiles synced in the past Don t want to extrapolate it across 5 different lockfiles Guess ignore is the best option

happy-kitchen-89482 · Answer

Setting to ignore is the 2 13 behavior so you re no worse off than you were But I d recommend fixing the issue by adding a pytest requirement either in your requirements txt or in a separate `python requirement ` target

happy-kitchen-89482 · Answer

It would need to be kept in sync with the version in the pytest tool lockfile which is not ideal but also not that bad

sparse-lifeguard-95737 · Answer

< happy kitchen 89482> in practice it can be a nontrivial papercut we ve got bidirectional comments in requirements txt and pants toml saying if you update this also update the matching value in and I d bet we still get into mismatched situations ~half the time because people are in a rush

sparse-lifeguard-95737 · Answer

when I was first getting involved with the project I remember seeing an issue about letting `pants toml` reference target addresses so requirements txt could be the source of truth for everything not sure what happened to the idea

ambitious-actor-36781 · Answer

and it gets worse for every tool you ve got its own lockfile for And grpcio pytest grpc introduce more cross lockfile locking and it s just generally unfun and hard to ensure you haven t fucked it up

ambitious-actor-36781 · Answer

and it kinda gets to the point of why not just have one lockfile

happy-kitchen-89482 · Answer

Yeah possibly allowing a tool to point to a subset of a regular lockfile might make sense

ambitious-actor-36781 · Answer

i was just going to say something like that Because you could still get into a situation where you ve pinned all the packages in your requirements extra requirements But if a dependency of your dependencies has updated inbetween you redoing lockfile A and lockfile B you potentially get a mismatch and issues

happy-kitchen-89482 · Answer

Wait I think we have a ticket for this

ambitious-actor-36781 · Answer

it does sound familiar

happy-kitchen-89482 · Answer

ambitious-actor-36781 · Answer

wait wouldn t the easier solution for pytest at least to be to set append the resolve for python tests to the `pytest default` resolve

happy-kitchen-89482 · Answer

well you don t want to use the entire resolve we d have to subset it

happy-kitchen-89482 · Answer

and we can t append because the two lockfiles might conflict

best-byte-73775 · Answer

< abundant leather 17386>