Preface:
The existing approach of using
subprocess(http://bugs.python.org/issue21880), did not yield good
result on 3 major platforms.
In this post, I am outlining an alternate approach
-----------


The proposed workflow is as follows

IDLE  <---> Middleware Generic API <---> Middleware Checker specific
API <--> Checker

IDLE and middleware generic api will go into Lib/idlelib. Middleware
checker specific api will go into site-package(usually a single file).
Checker, depends, but currently most checkers go into site-packages
anyways.

So, what happens is:
Whenever IDLE receives a request to check a file with a checker, it
requests the middleware generic api, passing on all parameters as
necessary.  The middleware generic api's only function is to pass on
the requests to the middleware checker specific api and return the
results back to IDLE.

The middleware checker specific api, will *import* the checker and do
the processing. It will return the result,(after formatting if
necessary).

Getting the checker specific api file into the users system could be
done through existing framework: pip
To ensure that the checker is present on the users system, we could
mark it as a dependency when uploading to PyPI.

For the middleware generic api to detect existing checkers: Create a
idlelib specific folder in site-packages(i.e. every middleware checker
specific api file to be placed into site-packages/idlelib/ to enable
detection)

Installation of middleware checker api could be done via command
line.(We could also support from inside IDLE, but that is a separate
issue altogether)
It could be something like : pip install idle-checker-x etc.

My proposal will avoid 'favoritism' in the checkers supported as well
as not hardcode any checker(and its interface to IDLE) into idlelib
-- 
Regards
Saimadhav Heblikar
_______________________________________________
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev

Reply via email to