https://pantsbuild.org/ logo
Join Slack
Powered by
Since upgrading to 2.14 we're now getting a lot of...
# general
a
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?
s
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
a
so I gotta add pytest to my requirements.txt, and keep it synced with my pytest lockfile?
s
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)
a
yeah, lots of pytest imports
we've set the inference option to ignore. But seems... suboptimal.
s
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
I will raise with the other maintainers to see if there’s a way we could make this UX better
it has personally annoyed me more than once 🙂 so I feel your pain…
a
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
h
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)?
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?
s
@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
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
a
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
and it kinda gets to the point of "why not just have one lockfile?"
h
Yeah, possibly allowing a tool to point to a subset of a regular lockfile might make sense
a
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
h
Wait, I think we have a ticket for this
a
it does sound familiar
h
a
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?
h
well, you don’t want to use the entire resolve, we’d have to subset it
and we can’t append because the two lockfiles might conflict
b
@abundant-leather-17386
3 Views
Open in Slack
PreviousNext
Powered by