brain_pytest and brain_gi should not import their underlying module (gi and pytest)

[PCManticore]

This breaks the static analysis contract since we're now importing third party libraries to build AST trees from them. While this makes sense for plugins, we shouldn't do this for core astroid, as it means we're now breaking the contract by importing live modules. Note that we currently do that with raw_building, but we only do that by default for builtin modules, while for third party modules we rely on --extension-pkg-whitelist option.

[lovetox]

I looked into this and i have some questions

how does pylint discover all members of a object that is imported from a third party module? does it search that module on harddisk and uses astroid to parse the python source code of said module?

If yes this is impossible for gi. gi is a wrapper around C libs which use the gobject framework. No parsing of python source code will yield the necessary class definitions and propertys to infer anything, because there is no python source code.

So what would be a good way forward?

Maybe a plugin that simply provides all the class definitions of all the libs gi wrapps? like a big stub file? And people could simply install this plugin if they need it?

Currently this stub file is generated everytime one calls pylint on a file, which is currently approx 5MB file, and this is what i think is taking so long.

[lovetox]

@PCManticore a comment would be appreciated, i would like to work on this, but i have no idea on the direction how to solve the whole gi dilema, thanks

[ernestask]

Yes, a comment would be nice if there is someone willing to solve the whole gi dilemma.

[gnacsa]

I also would be grateful for a solution.