PyIDE Plugin Planning

[rudi]

Ok, I'm trying to implement a finder based on configured paths (PYTHON_HOME, PYTHON_HOME/site-packages, PYTHON_PATH), maybe looking up 'pth' files as well. This will be an approximate search (not sure of the details yet) and will not use any kind of introspection. Maybe the PYTHON_HOME could be asked for the first time the dialog is opened.
In the meantime I'm temporarily adding a checkbox to the dialog so I can use the simple __import__-based algorithm (I have installed the plugin and I'm using it).

About the index: in my opinion that should be a tool in itself, that is, a general purpose index, a service other pytools modules could use, for example the completer. I mean, if you take the effort of managing an index (creating it, updating it, etc), maybe it is worth to store into it something more than the modules definitions and path.

[cody]

About the index: in my opinion that should be a tool in itself, that is, a general purpose index, a service other pytools modules could use, for example the completer. I mean, if you take the effort of managing an index (creating it, updating it, etc), maybe it is worth to store into it something more than the modules definitions and path.

Agreed, this could definitely be usefull elsewhere. It would be good to abstract as much of the common buisness logic into a base class as possible. I could see this being usefull for even things like project management. If the index is kept or representable as a basic python type (i.e list, dict, etc..) it would also make persistance easy. If we get something robust and generic to use for this I would like to include it in the Editra core code so it can be shared amongst other modules that may want to use it.

Thanks,

Cody

[rudi]

Agreed, this could definitely be usefull elsewhere. It would be good to abstract as much of the common buisness logic into a base class as possible.

I'll start thinking on it. In the meantime I've almost completed the core of the filesystem based finder. Some
details aren't yet well defined and implemented, but basically i'm trying to do a prefix and CI match.

If the user enters a simple name ("string") the finder returns (string.py, StringIO.py, etc) traversing recursively the whole path(s). This should take about 1 sec.
If the users enters a qualified name ("os.path", "email.mime.audio") the finder lookup path* and audio* under the specified packages.
Bugs apart, it handles cases like:

"os.path" => path.py or os/path/ does not exist, os.py exists => returns os.py
"ctypes" => ctypes.py does not exist, /ctypes/__init__.py exists => return ctypes/__init__.py

Not sure where/how/when the dialog to define the search paths root ("C:\python25", "/usr/lib/python2.5") could be placed. At the moment I'm using sys.prefix as a starting point to build the search paths. This includes /lib, lib/site-packages, PYTHONPATH items, .pth defined items.

p.s. Note that this function doesn't work on linux/mac at the moment due to my misunderstanding of the docs (on win32 you have sys.prefix\lib\site-packages, on linux sys.prefix\python-<version>\lib\site.packages). I'll fix it soon.

[cody]

Great,

I think we should have a dedicated configuration dialog for these tools as other parts of it will likely also be interested in knowing what python on the system to use.

Note the sys.prefix will only work for finding the prefix of the running instance of Editra. If the user is wanting to work with other version of python (i.e 3.0) then it won't be found via this method. So I propose adding a simple configuration dialog for this and pre populating it the best we can when the first time the plugin is used then leave it up the user to tell it what to work with.

My mind runs on Unix so I can probably work out any osx/unix issues when I get to testing . I am planning to start working on some extensions to this plugin after I get the next release of Edtira out the door.

My plans:

1) Add profiling support and output viewer

2) Unitest template generator. Takes a file and generates a unittest file with stubs for tests of each class/method/function found in the file.


Cody

[rudi]

Note the sys.prefix will only work for finding the prefix of the running instance of Editra. If the user is wanting to work with other version of python (i.e 3.0) then it won't be found via this method.

Of course. I'm using it as a default as long as I haven't written the dialog and as a default for unit and one-shot testing.

So I propose adding a simple configuration dialog for this and pre populating it the best we can when the first time the plugin is used then leave it up the user to tell it what to work with.
My mind runs on Unix so I can probably work out any osx/unix issues when I get to testing .

I'm mainly a unix (linux) user too. I'm temporarily stuck on Vista/Xp for professional reasons. Good chance (vista) to spot really strange bugs

About the conf. dialog: is there an established way to save/read configurations for plugins? The .ppb file?

[cody]

About the conf. dialog: is there an established way to save/read configurations for plugins? The .ppb file?

Yes I suggest using the facilities in Editra\src\profiler.py for storing configuration info.

Code: Select all

PYTOOLS_CONFIG = 'PyTools.Something'.

from profiler import Profile_Get, Profile_Set

Profile_Set(PYTOOLS_CONFIG, someValue)


Note: to use the profile facilities the objects being stored must be able to be pickled and be a builtin python type. Preferably one of the following types (dict, list, tuple, string, int, bool).

This is also only for configuration data, if you need to store large amounts of persistant data like we have been talking about with the index then it would be better for the plugin to keep its own data file in the cache directory.

Code: Select all

import util
store_path = util.ResolvConfigDir(u"cache")

OR

import ed_glob
store_path = ed_glob.CONFIG['CACHE_DIR']


Cody

[rudi]

Yes I suggest using the facilities in Editra\src\profiler.py for storing configuration info.

Ok. I added a dictionary to the main configuration. It contains just one key now (the choosen base python path) but I leave it open for more keys) and it's missing a way to change the configuration (i could add it somewhere in the find dialog or wait for a common interface for plugins configuration).

Can you give it a try on osx? I tested on windows and linux but I haven't a Mac. I assume that on MacOSX python is laid out exactly as on linux: sys.prefix is something like '/usr' and python libraries are laid out like this:

/usr/lib/python-<version>/
/usr/lib/python-<version>/site-packages

'/usr/lib/python-<version>' is what you must configure.

I just wanted to be sure that the search path is correctly built.

The search algorithm is not completed yet but it is - I think - already usable and useful. The bug is that when
you insert a path like aaa.bbb.ccc it should not returns any ccc*. The aim, at least now, is doing a prefix search: aaa matches aaa* anywhere, BUT a qualified module like aaa.bbb should match only aaa.bbb* or aaa/bbb/__init__.py or, if nothing matches those two, at least aaa/__init__.py (this way you can find os.path in os.py for example)

[cody]

Ok. I added a dictionary to the main configuration. It contains just one key now (the choosen base python path) but I leave it open for more keys) and it's missing a way to change the configuration (i could add it somewhere in the find dialog or wait for a common interface for plugins configuration).

Just hold up a bit longer I almost have the common interface ready. As you may have noticed I re-wrote the entire plugin dialog ui last week. I just need to add a few minor extensions to the base plugin class and hook it into the new ui in the dialog and it will be possible for plugins to supply a config dialog there.

Can you give it a try on osx? I tested on windows and linux but I haven't a Mac. I assume that on MacOSX python is laid out exactly as on linux: sys.prefix is something like '/usr' and python libraries are laid out like this:

Sure I will try to give a try sometime soon. I want to start adding some stuff to this plugin in the near future too. Just want to finish up a few more tasks in Editra first.


Cody

[cody]

Ok,

The plugin configuration interface is in place now (still a few loose ends but its usable) and I have updated the Launch plugin as an example of how to use it. Documentation to follow hopefully within the next week.



Cody