To prevent frustrated tester, we should let buggy code to be generated instead of failing the project generation (if it failed on the linter) by appending a # TODO line on the code.
---------
Co-authored-by: majdyz <[email protected]>
Subprocess execution implementation (for Ruff & PyRight) is currently a blocking call. This doesn't work well with the event-loop used by the fastapi.
Scope:
Make AiBlock.validate async
Make subprocess execution async.
---------
Co-authored-by: majdyz <[email protected]>
Integrating PyRight project-based code-linting. This will allow us to detect:
* Misuse of async functions.
* Misuse of optional type and other annotated types (currently disabled)
* Wrong usage of pydantic and prisma model.
* Wrong usage of third-party library.
* Use of undeclared field
* Use of uninstalled third-party library (which will prompt LLM to add the requirement list)
Known trade-off:
Setting-up PyRight requires building a full-project (generate the Prisma model code, installing 3rd-party library, compiling the function with the object dependency) this slows down the code-validation during the code-validation step.
---------
Co-authored-by: majdyz <[email protected]>
Co-authored-by: SwiftyOS <[email protected]>
This is a large but a much needed change to allow more sophisticated static code analysis to be added.
PyRight (used by pylance) will allow us to detect:
Misuse of async functions.
Misuse of optional type and other annotated types.
Wrong usage of pydantic and prisma model.
Wrong usage of third-party library.
The overhaul is required to allow us retrying while fixing the code as a project (not only as a function) and allow us to keep adding non-LLM fixes to it so that we can avoid wasting the retry.
The scope of this PR is still a refactoring and the adding of the PyRight linter, so this PR try to keep the existing behaviour.
The enablement and more tuning on the linter will be done in the followup PR.
---------
Co-authored-by: majdyz <[email protected]>
