Create python bindings for in process checks#4002
Conversation
|
Hi @tylerriccio33! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks! |
Summary
This draft PR is to pair #3964 and show an example of how the in process API could work, with bindings directly to the rust code via pyo3. I can't think of another way to do this without adding a new crate and pyo3, which could be undesirable from the dependency standpoint.
Perhaps this functionality should be made optional?
Fixes #3964
Test Plan
I add a simple rust test and a python test to go with the crate. I wanted the python test to capture the fact we have the pyrefly.toml file and the helper file which we import from. Another nice thing (which @yangdanny97 pointed out) is this plays off lsp mode so any future checks would be against the warm checker
If this direction is approved I'll of course drastically expand the test suite
FYI - I used claude to help me figure out how the playground worked, since I was having trouble determining a few things. Honestly never worked in codebase this size in rust