cyn.in buildout: The omelette recipe

August 6, 2009

We've been working on improving the cyn.in buildout for the upcoming version. One of the things we've added is the collective.omelette recipe. Leaving the funny name aside, (it's a pun intended on the fact that pretty much whatever you do in a buildout is based upon pre-defined “recipe”s and that this one is really special in that it mashes up all the code in all available products, projects and everything that's there in your buildout together into a single linked folder chain. And if you didn't get the pun, ignore it, it'd not important for the rest of the stuff here.)

Let's start with the usual alert:

Warning

Danger, Will Robinson! Geek Developer alert!This video and blog post is for the software developer audience. And probably only of interest to people who think that building out cyn.in from source is pretty cool, and would appreciate another productivity tip that would greatly enhance their way of working with cyn.in. Everybody else will probably not make much sense of this, but is of course welcome to try, and fit in. 😉 Ok. So here's my list of assumptions:

You got cyn.in working from buildout
You're surprised at the complexity of the codebase - all of cyn.in stuff exists in the src folder, but when you go into parts, and eggs, there's just too much stuff there to really comprehend and figuring out which code goes where, is really painful. This recipe is for you.
You're getting a hang of things. You understand that most of the plone codebase is concentrated around the CMFPlone product, and then you look for plone's kss and you can't find it, for example. This recipe is for you!
You'd actually like to use a GUI IDE tool to work with, rather than just using Notepad++, gedit, vi, or whatever else it is that you do use for that sort of thing. Something that will give you intellisense for autofilling function names, showing you function arguments, and doing reference lookup jumps into outside code files, when the need arises. This recipe is for you, also.

In this video, I show how one can add the plone collective recipe called Omelette to your buildout. And then how it can be used for fulfilling the above.In this example, I show how the Komodo IDE product from ActiveState can be set up to work with cyn.in. This will give you the above intellisense, and yes, that's a major improvement over what you do currently. You could alternatively set up Wingware's Wing IDE for the same effect, in the same way, (and then some - in that you can actually hit debug breakpoints, and inspect variable values, but I use Komodo IDE to show this off because it's a bit simpler to set up and to use as well). And then there's some other IDE projects out there, but I'm unsure of their maturity.The first step is to get a normal running buildout.Then you just add a new “part” to your buildout and then configure it to the way you want it to be. In the setup I show, (which is the way it's going to be present in the upcoming code-base in cyn.in), we're setting up all source code in a predictably named “allsrc” folder, which is a sibling to the currently existing src folder that you're possibly already comfortable with.Once you build the buildout after you add the new part to it, you'll notice the folder getting created, and then when you go into the folder and have a look, you'll see that all source code that you need is neatly arranged in non-nesting folders. This is the linux “ln” command at it's finest, your code is not actually copied, it's just linked to. And yes, this recipe only works on linux, for now. All of zope, plone, cyn.in and all constituent products will be available in the allsrc folder after you run it, all linked up to go to their original locations, but still usable directly as it is available in the allsrc folder.

Cool?

Did you really get that?Let me restate. The code files you're staring at in the allsrc folder are not actually present, there. They're still at the original places they were at. This is a convenience recipe to “virtually” aggregate all the source code into a single root folder. Do not be confused when you're using your version control system (svn,git,mercurial whatever) with this.That said, editing the source in the allsrc folder is perfectly fine, and in fact that's the whole idea in the first place! Your code, your edits will all be done in this conveniently rooted folder, from your IDE. Just be careful that you're editing your own code and not going modifying plone itself, or any other external (non-development) egg directly. If you do this, your code will actually work on your instance, but will not go to other developers when you commit it, and worse, when you re-buildout, your changes will be overwritten - editing base stuff is still to be done in the normal way, by overriding and subclassing, and so on, in your own products.The video shows how convenient navigation becomes. Note the simplified folder chaining, there's no need anymore to have src/ubify.xmlrpc/ubify/xmlrpc and then, the code for it. xmlrpc is directly available at allsrc/ubify/xmlrpc, with the other parts lining up right beside it.Once you've looked at the refined code structuring that the Omelette recipe does for you, then it's time to move on to the next phase, actual editing. The video shows how easy it is to configure your Komodo IDE project to point source code lookups to the allsrc folder, and then goes on to show how the in-code lookups for functions, arguments and Ctrl+Click jumping to actual resource works.Try it out, it really aids in understanding the code flow.

cyn.in buildout: The omelette recipe

Warning

Cool?

Links: