Notes on configuring Zope and Pylons

Just wanted to note that recently I added a (rather short) how-to on configuring Pylons in the sourceforge forum

And for those configuring Zope, there is one little catch... Zope actually has multiple locations with a 'Products' folder (and the parent of those Products folder must be added to the pythonpath... to the system pythonpath if it is a part of zope or to the project pythonpath if it is a part of your project)...

Now, the catch is that the Products folder does not have an __init__.py file... so, pydev won't recognize it as a valid python package unless an __init__.py file is added to each of the Products folder...

Apparently zope does some 'hacking' with the pythonpath itself and adds some black-magic to the mix instead of using the regular python import structure, to have multiple 'Products' scattered around (python would usually find the first one and not get the other Products)... still, it seems that adding those __init__.py files won't have any side-effect on zope itself (and will enable code-completion / code analysis for your projects).

Update: some more details were added to: http://pydev.blogspot.com/2007/05/debugging-zope-in-pydev-extensions.html

Pydev release 1.2.6

Ok, the release is out, and it seems everything is well ;-)

One source of complaints was that some had updated pydev and not pydev extensions, and this was not working well... so, I've taken a look and the problem is that when I specified the pydev extensions plugin, I asked for a 'greateOrEqual' match on the version, when a 'perfect' match is what's needed (otherwise, you could get a bunch of error with accesses to invalid methods, attributes, etc)

So, this is fixed for the next release... but until there, those that use both have to remind to update both.

Now, planning for the other release...

One of the nicest things added in the extensions is probably the rename refactoring (which is out, but still in beta), so, I'll probably try to improve the rename refactoring to include matches on strings and comments, and an option to match 'imprecise matches', so that the user can review other potential matches that the pydev analysis ended up discarding.

On the pydev side, I really wanted to go more for the package explorer... it has one issue that I think is critical (commented on: a previous post), and the way to go is probably recreating all the resource-based actions myself... as this can be tricky, I'm not sure it'll be available for the next release...

Long time...

Yeap, it's been quite some time since my last post, but I've been busy ;-)

Right now, the aim is getting things ready for the pydev 1.2.6 release (which hopefully will happen this week)...

Pydev already had many fixes, in the package explorer, templates, changes from Thread to the Job API, etc, etc.

And in pydev extensions, the next version will implement the refactoring for rename... Still the first release, so, it should still be regarded as beta, but it already features a preview for the refactorings, undo/redo (both courtesy of the Eclipse framework), and should work for most rename refactoring cases, such as classes, methods, attributes, parameters, modules (although you have to make this refactoring through some import, because it is still not integrated in the package explorer)...

As it is beta, please take some time and review the changes it will do... and report if you think it forgot to rename something or renamed more than it should -- but have in mind that you're refactoring python, and as it is very dynamic, some analysis might not even be possible (but should probably be ok for 90% of the cases).

And another nice thing is that there is a really cool project called PEPTIC that will add other refactorings to pydev, and should shortly replace BRM as the default refactoring engine in pydev (that will probably happen around march)...

Package Explorer status for Pydev

Well, the cvs implementation already had some nice improvements when compared to the current version (such as working with a working set), but there is one issue that is worrying me.

Basically, the current Eclipse CNF (Common Navigator Framework) has a critical bug for me, meaning that it has a little delay when synchronizing actions with the selected resource (the bug is reported at the eclipse bugzilla ), and it can be nasty... got me to delete a whole source folder instead of a single file, so, I guess I'll have to replace all the actions for the resource actions before actually considering it mature... Still, it already is a good way for browsing your project (although it still does not have the 'flat' mode implemented).

What's going on in pydev

Ok, almost 3 weeks without posting anything...

I'm still working in the package explorer implementation for pydev. I think most current bugs are solved, and what's still missing before a release is handling working sets correctly (which I hope won't take too much).

After taking a look at the way I should handle it, it appears that my ITreeContentProvider implementation (hierarchy below) must be able to handle an IWorkingSet:

BaseWorkbenchContentProvider (ITreeContentProvider)
--> PythonBaseModelProvider (IResourceChangeListener, IPythonNatureListener)
----> PythonModelProvider (IPipelinedTreeContentProvider)

So, basically the inputChanged(Viewer viewer, Object oldInput, Object newInput) method from the PythonBaseModelProvider must be extended so that it works accordingly if the newInput is an IWorkingSet. I hope it won't prove too difficult (but I thought that creating the IPipelinedTreeContentProvider -- which is basically replacing objects that are from the resource domain for objects that are from the pydev domain -- would be very easy, but it ended up not being that straightforward (anyway it seems that it is already working correctly).