feat: implement add_extension in Python binding

[paulolieuthier]

That's my first PR to the project. Please, tell me if there is a better way to do it.

[paulolieuthier]

@microsoft-github-policy-service agree

[anakrish]

Hey @paulolieuthier, Thanks for the contribution.

This looks good. Some suggestions:

Add more tests. E.g:

• Error propagation: What happens when the Python callable raises an exception?
• Type diversity: Passing/returning dicts, lists, sets, numbers, booleans, None
• Zero-arg extensions
• Duplicate registration
• Wrong arity
• Passing a non-callable object

[paulolieuthier]

@anakrish can you take another look?

[anakrish]

@paulolieuthier I have a few more comments. Also we need to note somewhere the clone semantics. That is if an engine instance is cloned, it will share the same python instance and the builtin invocations themselves will be synchronized.

[paulolieuthier]

Fixed!

[anakrish]

@paulolieuthier Looks very good. Can you also explain the clone semantics in the help for the extension method.

/// Note: When the engine is cloned, extensions share the same Python callable
/// reference rather than being deep-copied. Stateful callables will share
/// state across clones.

[paulolieuthier]

Sorry, I had missed your request to improve the docs. I believe it's ready now.

[anakrish]

@paulolieuthier LGTM. Thanks for the contribution!

Can you also share your usecase for this feature?

[paulolieuthier]

Sure! We are experimenting with Rego as a language for our feature pipeline (for a feature store). As our features are defined in Python, we need good Python support to run tests. On production, the features will be evaluated in a Go server, and Rego's Go API is feature complete. So we figured we could help fill in the gaps of the Python bindings.

[paulolieuthier]

BTW, are you planning to release a new version? Or should we just pull from main?

[anakrish]

BTW, are you planning to release a new version? Or should we just pull from main?

I will make a release next week once #582 also goes in.
Note that we are pivoting to a Rego Virtual Machine based evalution of different policy languages.
https://anakrish.github.io/rego-virtual-machine-playground/

The RVM is currently exposed to python; we will likely need to implement extension capability in the VM instances as well. So maybe it might be beneficial to maintaing a global table of extensions as opposed to per Engine/VM instance.