[code-quality] Re: adapting code quality tools to non-traditional situation

На 18.10.19 г. в 15:12 ч., Ian Stapleton Cordasco написа:

Hi Mats,

I can't speak for pylint, but Flake8 allows you to specify --builtins when checking things (which we use to alter PyFlakes' understanding of what is a built-in). Based on what you described, I think that would allow you to do something with Flake8 locally or to steal some of the Flake8 code to make your own `scons --check`.

Pylint (or rather astroid) has the concept of transformation plugins which can teach the tool about the underlying API. Such approach is used by pylint-django: https://github.com/PyCQA/pylint-django/tree/master/pylint_django/transforms pylint-django also uses so called augmentations, mostly to ignore some checkers depending on context: https://github.com/PyCQA/pylint-django/blob/master/pylint_django/augmentatio... I don't know about other tools but it is relatively easy to figure out how to create plugins for pylint. I can send you more examples about the augmentations stuff but to my knowledge it is very sparsely documented. If you decide to go this way the biggest unknown would be how much augmentation you will have to do to teach the linter about scons API. Could be relatively straight forward, could turn out to be PITA. -- Alex

Cheers, Ian

On Thu, Oct 17, 2019 at 11:25 AM Mats Wichmann wrote:

...

I'm fishing for pointers here, this isn't really a specific question I'm expecting a magic answer to - though one such would certainly be gratefully accepted :)

I work on the scons project - scons is a software build system tool, which is controlled by configuration scripts which are written in Python; scons is itself written in Python as well. It would be nice to have the ability for users to be able to check their configuration scripts for errors, poor programming style, etc. We certainly get enough questions about people who have actually botched the Python in their scripts, rather than finding errors in scons itself.

However - scons is not a Python module that you import to make its methods and attributes visible. Rather you run scons the program, and it finds the build scripts and interprets them using Python within the context of the already running program (i.e. exec(compile(scriptdata, ... ). That means if you run, for example, pylint on a perfectly valid script, it will certainly complain, because of the use of the scons "API" which will be well known during the run context but completely unknown to a static checker tool that does not operate in that context.

So the scons model seems to be at odds with how all of the checkers I've looked at operate. I'm thinking that any possible way forward would be to have the checker operate in the scons context - that is, rather than expecting to run it from the command line, it would be activated by something like "scons --check". Anybody have any ideas how one could adapt something to this model? How would one teach a checker what it needs to know about the API? Or is it simpler than I'm making it out to be?

thanks

-- mats _______________________________________________ code-quality mailing list -- code-quality@python.org To unsubscribe send an email to code-quality-leave@python.org https://mail.python.org/mailman3/lists/code-quality.python.org/

_______________________________________________ code-quality mailing list -- code-quality@python.org To unsubscribe send an email to code-quality-leave@python.org https://mail.python.org/mailman3/lists/code-quality.python.org/

-- Alexander Todorov Co-founder & Open source QA at Mr. Senko http://MrSenko.com