[PATCH] Always notify when CompiledModule is created
Brought to you by:
fabioz
Menu
▾
▴
#804 [PATCH] Always notify when CompiledModule is created
The motivation: we have some python extensions written in C/C++ that cannot be analyzed by python source code parsing. So we add them to list of built-ins to get the completion data from python process. This does not work too for several reasons like architecture problems (32/64 bit default vs. given project) or path (actually the library depends on other library that is loaded from some place...).
An easy way how to fix that is this patch where I can get notification add do my own processing to add tokens.
More general solution would be to allow registration of Module builders (through some extension point) where I could add my code that can provide data for modules like the extension mention here. And if no extension creates the data the default path would be used.
Discussion
patch against 1.3.24
I am adding also my version of modifications to pycompletionserver.py. While I used a slightly different one there is the idea: run pycompletion and pass module name as an argument in these special cases where the server is not flexible enough. Then it is possible to read stdout. It can be also merged into pycomletionserever directly and probably it would be a good idea to do something like this for testing too. Starting a socket communication in tests looks like overkill to me.
File Added: pydev_pycompletion.py
a patch for pycompletionserver.py
Actually, the next release will almost fix it (with interpreter per-project), so, what'd be missing is that environment variables is also specified on the interpreter (there's already a request for that and it'll be done on 1.4.3)
Another request that also appeared is to give a way to actually specify a module in some way that does not require the runtime introspection (which will be done on 1.4.3 or 1.4.4), and the solution will probably be having a way to define a module in some structure (probably xml) and feeding that to Pydev to use and give code-completion/analysis.
So, I think those would be the 'right' ways of fixing it (so, the patch won't be applied, as I think it's a workaround for something that'll be fixed soon)
OK, sounds fair.
Then I have a comment about specifying a module: declarative definition of a module can work for some libraries that are not changed too often. It means the info is fixed for them. I think that adding an extension point to supply custom module data provided can be more general. Basically a factory to create a module data given the module name and optionally its file path and/or project. Does it seem reasonable?
Very reasonable... The idea is that the structure underneath provides for an extension point for providing those, and a default is provided for the static info, but clients should be able to plug into it in other ways.
I'd like to reopen this one. You've outlined solution that sounds OK in general but still does not fit fit our needs. To analyze our modules we need to analyze them using a setup that is associated with module name. I mean setup used for project basically does not work for our execution. This change always notifies registered listeners and provides just one place where extra token definitions can be added.
Note that this is currently the only patch to pydev that I need to maintain so it would be great to see this integrated. Then we could skip own own build of pydev!
I didn't understand why the possibility of having multiple interpreters with the possibility of adding environment variables for each fix it for you, but taking a 2nd look at the patch, I think there would be no problem applying your patch as it makes customization more flexible for clients, so, I'll apply it and make it available for the next release.
Applied for 1.4.5 (svn: 2701)