Am I right in thinking that `run_rule_with_mocks` ...
# development
h
Am I right in thinking that
run_rule_with_mocks
doesn’t work with call-by-name at the moment? At least that is what I’m seeing.
cc @wide-midnight-78598
Specifically, it appears to have an issue with
concurrently()
awaiting multiple calls-by-name
I see https://github.com/pantsbuild/pants/pull/21144 by @worried-painter-31382
The issue seems to be that here the elements we call the
get()
helper on are the raw coroutines, not the
Call
wrappers.
Indeed, this is
tuple[Get | Coroutine, ...]
and not
tuple[Get | Call, ...]
w
Makes sense! Like I wrote in the issue I wasnt and arent sure
run_rule_with_mocks
has a place in call-by-name
Module patching is "the way" to mock functions in python, after all. Sure, the tests would need to be async and the mocks has to return awaitables, but writing utilities for that is like 2 lines of code and
pytest-asyncio
works fine
concurrently
complicates that option a little bit, but I think maybe deprecating
run_rule_with_mocks
and providing a facility to mock
concurrently
, possibly a patching context manager that just causes
concurrently
to return the input arguments ~ as is would be much more intuitive in a unit test context.
Argument being that
MockGet
mirrors
Get
, not
call_by_name
.
h
Agreed! I’m experimenting with that now, in fact.
👍 1
It’s a bit more complicated, since the named thing you naively patch is actually the
Call
wrapper, not it’s underlying
.rule.func
, and that thing is a field in a frozen dataclass so you can’t naively patch on that either…
✔️ 1
But I think I will be able to get this to work with some Python hammers