I also wasn't sure if each of the rules should just be a shim into calling something like this - but it felt like I was muddling rule registration with runtime calls

native_engine.tasks_add_call(
                    tasks,
                    awaitable.output_type,
                    awaitable.input_types,
                    awaitable.rule_id,
                    awaitable.explicit_args_arity,
                )

Or alternatively, if we're trying to emulate the

Get

stubs, using

PyGenerator...

? Anyways, this is my first real foray into the engine code and interface, so I clearly haven't grokked the interface semantics yet

Leaving it here for the weekend: I'm trying something like this to see what happens:

async def remove_prefix_request_to_digest(value: RemovePrefix, **kwargs) -> Digest:
    return await Call("remove_prefix_request_to_digest", Digest, (value, ), kwargs)

But it doesn't seem to matter what permutations of input args/kwargs, and Call-mapped args/kwargs I get: > TypeError: Invalid Get. Because the second argument was a dict, we expected the keys of the dict to be the Get inputs, and the values of the dict to be the declared types of those inputs.

at a fundamental level, they are just callable functions. but because of the type-driven registration, we had to expose them via their types.

i think that you're sortof on the right track with exposing them: we should expose all of them as methods from the native module and then ... use a sortof

@rule

explicit decorator to annotate them with their requirements?

i'll see if i can do that today.

My first idea was to expose them all as pyfunctions, but the whole thing fell apart in my Pants knowledge as my original assumption was that they needed (by design of rule calling) to be called in a special way to satisfy the async runner (e.g wrapped as `Call`s).

but because of the type-driven registration, we had to expose them via their types

Gotcha, I wasn't sure of the correlation vs causation here - I thought they were exposed via types as a call optimization, not due to registration.

i'll see if i can do that today.

I can do the bulk of the grunt work later this week of exposing the rest of the functions, if I have a framework/example/whatever to run off of. It would definitely take me a while to learn what I need to, and then build new functionality from the ground up myself - with the lack of retained knowledge of the runner + rule system

first cut at a solution (using the pyo3-asyncio crate) isn't quite working, but might if I actually start an asyncio event loop.

here's the branch so far: https://github.com/pantsbuild/pants/compare/stuhood.intrinsics-as-native-decorated ... it compiles, but it fails because there isn't an asyncio event loop running. i'll need to figure out how to ensure that one is running/configured.

In the meantime though, it would probably be fine to execute the rewrite for all the other method calls in the Pants repo? Then folks could gain some experience with it, and flush out some bugs?