На 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/augmentations
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 <m...@wichmann.us> 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-le...@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-le...@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
_______________________________________________
code-quality mailing list -- code-quality@python.org
To unsubscribe send an email to code-quality-le...@python.org
https://mail.python.org/mailman3/lists/code-quality.python.org/
