PyCON 2006 Sprint Recap ======================= A while back, it was suggested to me to participate in the PyCON 2006 sprints so that I could work with Jim Fulton and Tres Seaver on improving the story of local component customization. PyCON was definitely going to be a good opportunity to meet in person for a whole week, so I presented this idea to a couple of companies in the Zope community. The following companies were kind of enough to sponsor me for this trip (alphabetical order): * `Blue Fountain `_ * `BubbleNet `_ * `Code & Syntax `_ * `com.lounge `_ * `Infrae `_ * `Netsight `_ * `Nuxeo `_ * `Zest Software `_ I'd like to thank all of them for their kind support! I just returned from this 10 day trip Sunday night and have been trying to catch up with everything here in Shanghai ever since. So here's finally my own little PyCON sprint recap. The Conference -- and how I missed most of it --------------------------------------------- I left Shanghai on Friday, 24 February in the afternoon and reached Dallas the same day -- in the afternoon. Crossing the dateline, baby! Having quickly put my stuff in the room I shared with `Felix Wiemann `_ and `Duncan McGreggor `_, I landed in the hotel bar with Tres, Theuni, and the `Hendryx brothers `_. The night ended at `The Flying Saucer `_ right across the street of the hotel. They had approx. 150 beers on tap and very cute waitresses. We went there on Saturday as well, just with a bigger crowd. I even got to have a chat and a dance with a nice local girl. The sacrifices I make for King and Country... The conference was ok. For some reason I like EuroPython better. Perhaps because there's more Zope going on, or more other interesting talks. Or just more people I know. Or perhaps because I had large hang-overs from all the *good* (for the first time in the USA!) beer on Friday and Saturday night. Guido gave a boring keynote as usual, Jim announced his "two visions" idea which turned into an irritating discusson the mailing lists afterwards, and Django and TurboGears obviously got all the hype. Luckily, `Chad Whitacre `_ pulled his secret weapon, the 20 second wiki! See that, Ruby on Rails? We don't need no 20 **minutes** anymore, we can do it in 20 **seconds**! Oh, and by the way, immigration didn't turn out to be much of a problem. Even though I had (correctly) stated China as my country of residence, I passed through immigration just fine... the immigration officer was a very nice Chinese woman! Sprints -- what the others did ------------------------------ We met on Monday morning for the sprints. We had quite a number of Zope sprinters for the `first two days`_: * Andreas Jung was desperately trying to finish his work on bringing the Zope 3 ZPT engine to Zope 2. He ran into many problems, it seems. His branch is still pending to be merged. * Michael Bernstein and Steve Alexander dove into the innards of the Zope 3 publishing system, striving to be inspired on how to simplify it. Steve hinted at the possibility of getting rid of the publication object all together and rather moved to a more *eventy* system (instead of a *subclassy* one we have now). * Theuni and Christian McDonough picked up their now one-year-old ZODB blob project. I have no idea how far they got. Theuni also did some Common Criteria stuff after Chris left. * Nathan Yergler and Paul Winkler experimented with eggs. From what I saw, most of their time was spent in brainstorming, fiddling with setuptools and biting their legs off out of frustration. Especially towards the end of the sprint, Jim was largely working with them. I won't steal their thunder here as they will probably soon be able to report on some things they have thought about, especially how to sanely wed egg dependencies and development checkouts of packages. * Jeff Rush, Brad Allen and Broadus Jones, three chaps from the local Python/Zope user group, joined in as well and learned about Zope 3, though most importantly, they organized a lot of the things behind the scenes and made everything go so smooth for us that we didn't even notice. A big thanks to them! .. _first two days: http://palladion.com/home/tseaver/obzervationz/2006/pycon_sprint_20060227 *Customize* -- hit me baby one more time ---------------------------------------- Sunday evening, after the conference, we had a small brainstorming session on local components. It was very use case and end-user story driven which was good. Alan Runyan, Calvin Hendryx-Parker, Tres Seaver, Jim Fulton and others were sharing a lot of stories on how they use and would like to use local component registration. We basically came up with: * The *Customize* button is useful for the newbie who wants to try things and doesn't have filesystem access. Not giving filesystem access to everyone is also useful. * The *Customize* button is also useful for developers who normally would have filesystem access, for example when they want to fix a bug in a running application without deploying a new version of the whole software. * Issues like being able to define local configuration from ZCML or having ZCML-defined components being refreshed while changing them were found to be orthogonal to the browser view customization that happens persistently, using the *Customize* button. So, we decided to focus on the *Customize* button for this sprint. The next challenge was that in Zope 3, a view really is an instance of some sort of view class. Thus, there are different ways of customizing a template-based browser view: 1. A standalone template needs to be customized. This is the easiest case. 2. A template using methods of a view class needs to be customized. The customization only involves the template, but not the code in the view class. 3. A template using methods of a view class needs to be customized. This time, the customization also involves the view class, or the customized template simply needs more or different view logic that also needs to be kept in an associated view class. The third point can really only be adressed by defining a view class persistently and registering it locally along with a persistent template. The first two cases, however, could be solved by giving the customized template the view class of the original view. User stories and dependencies ----------------------------- On Monday morning, Tres and I paired up for sprinting and turned the *Customize* button use-case into a user story. From the doctest: 1. Making a folder a site 2. Walking up to an object and getting a list of its template-based views 3. Selecting a particular view, seeing its template source and deciding to customize it 4. Customizing the template and seeing the customized template take effect 5. Deleting the template and seeing the old view take over again We wrote a science-fiction doctest for this and then implemented the machinery behind it. Tres left after two days, but we had enough in place so that I could finish it and get a working prototype by the end of the sprint. In the meantime, Jim was working on the implementation of his `Local Component Management Simplification`_ proposal, with a little help from Tres and myself (which mostly involved breaking his tests *grin*). The global component registration stuff was already done (though it produced tons of deprecation warnings), he now was creating a persistent version of the component registry for us that we could use in Five and that will also be used in Zope 3. .. _Local Component Management Simplification: http://dev.zope.org/Zope3/LocalComponentManagementSimplification The new component registry API is much cleaner and easier to use than the one Zope 3 currently has. Since Five and Zope 3 will share the same code, it will also let us get rid of a home-grown and rather immature local component implementation in Five. Going home ---------- On the plane to Tokyo I did my last refactorings on the prototype. I think the sponsoring idea has worked. We sat down in Dallas, talked about the use cases and produced something that works and will be the basis for code in actual releases. And this only came at a minimal cost for the sponsors since they pooled their sponsorship. What is left to do? We need to finish Jim's work on his Zope 3 branch and get it to be merged to the Zope 3 trunk. We need to finish the customization prototype on the Five branch and get that to be merged to the Five trunk as well. So, unless we encounter major scheduling problems, Zope 2.10 will be fully equipped for local customizations of Zope 3-style views! Where do we need help? Jim's ``jim-adapter`` branch of Zope 3 works, but throws a lot of deprecation warnings. Some of them just involve trivial renaming, some involve pulling important strings out of a huge cloth. My guess is that Jim won't have time to handle this all by himself. Also, the UI I'm creating in Five for customizing views is really crappy. Perhaps someone could help me there... How to check this out? Get a checkout of Zope 2's ``philikon-local-components`` branch. Create a folder and it turn it into a site. Inside that site you can walk up to any object, get a list of its Zope3-style views and customize one of them. `The doctest`_ should do a sufficient job of explaining the steps to Python programmer. .. _the doctest: http://svn.zope.org/Products.Five/branches/philikon-local-components/component/zpt.txt?view=markup