The good news I want to announce is that the buildout-based Plone Installers for Windows have been updated, and a few bugs have been fixed in the process. Namely:

1. Running ‘bin\buildout.exe’ would not show any output. That was because it was generated by running ‘bootstrap.py’ with ‘pythonw.exe’, so that a command prompt would not flash on the screen. I added an extra step at the end that re-runs ‘bootstrap.py’ with ‘python.exe’. So a command prompt will flash quickly, but at least it works right.

2. The version of ‘setuptools’ being shipped in the buildout installer was still ‘0.6c8’, which did not work with Subversion 1.5. At least one person was affected right away by this, and I only found about it because I was watching the #plone channel closely.

To fix those problems I had to make two extra releases, because they came to my knowledge after the release was already uploaded. So if you downloaded an early build of the Plone 3.1.6 buildout-based Installer for Windows, go and fetch the latest build. Otherwise, if you are willing to play with Plone 3.2.0a1, go and fetch that instead.

This week, with the Plone Conference 2008 going on in Washington and the fact I did not attend this conference, I finally made enough time available to get my hands back into Zope again.

So it’s my pleasure to report that after about a week of hard work and a handful of workarounds that will need future cleaning, Zope 2 does now startup under Python 2.6.

My expectation with this now out of my way is that other developers will start looking at adjusting third-party applications (hint: Plone) to run on Python 2.6 as well.

The code is available on the gsoc-python-2.5 branch of the Zope repository, and the lucky guys at the Plone Conference will be amongst the first to hear the good news through Matthew Wilkes, which registered for a stealth Lightning Talk which should get at least some people puzzled. I would love to be there and see their faces when Matthew unveils the surprise.

Big thanks go to Tres Seaver for helping me figure out a change needed in Zope’s private version of ‘medusa’ and to Ranjith Kannikara, our GSoC student through the Zope Foundation, and his friends which did a good chunk of the hard work, namely figuring out changes to the C-based ‘Acquisition’ module and cleaning up string exceptions.

NOTE: This is not intended for production yet, it is just a technology preview to get developers to try out and start porting their own projects. Many bugs still exist, some of which might take up to a month to get fixed. Most importantly, the RestrictedPython implementation has not been fully audited for the new builtins and language constructs introduced since Python 2.4.

EnSimpleStaging is based on ZopeVersionControl, another great product which provides for keeping a repository of versioned objects inside the ZODB. One issue we’ve hit constantly with EnSimpleStaging was that certain methods from ZopeVersionControl depend on an actual transaction being commited to properly detect that an object has changed. While in real life this specific method will always work flawlessly due to the way using ZopeVersionControl and EnSimpleStaging works, in a test case it was very hard to test this, due to the fact that a test case is run within a single transaction which is aborted at the end of the test.

Sometime ago I’ve learnt that ZODB has a nifty feature: it is possible to wrap any Storage instance with a DemoStorage. After you do that, you can commit changes and they will be committed to the DemoStorage but not to the base Storage. That would solve not only my problem with ZopeVersionControl, but can potential solve a whole lot set of problems due to expensive setup methods in test cases.

That fact has lived in the back of my mind for longer than two years, until today I set some time aside to investigate a way to implement this cleanly in a way that could be used for my tests. Searching around, I’ve found at least a couple occurrences of other people trying to do the same. I didn’t find any solution though, so that either indicates they just gave up or that they found a solution but didn’t care enough to share it. In fact, the title of this post was borrowed from one of the message subjects, in hope that it will make it easier for other people to find a solution in the future.

My solution (with a test do demonstrate that it works) was based on Jim Fulton’s suggestion to look at zc.selenium. I’ve simply adapted it to the Zope 2 reality, using ZopeTestCase’s provided hooks and `Zope2.bobo_application` (which is the Zope 2 equivalent of the publication object from Zope 3).

Hopefully this will be of use to more people, specially to the folks that were seeking for ideas about how to implement this. It would be even better to just add this to ZopeTestCase proper, I think. Maybe someone will be interested in doing that.

I have already visited the US in June, when I attended the Plone Symposium in New Orleans. On that occasion, I stayed in the US for ~30 days. This time around I was planning to bring my wife and dog (the cute Yorkie pictured at the top of this blog).

One thing that worries me though is that I’ve never took my pet on any flights, so I have no idea how pet-friendly airlines are. Just to get from Sao Paulo to the US (Houston) it’s a ~9:30h flight. My dog is usually cool with traveling. Earlier this year I drove nearly 8h to the beach and we stopped twice on the way, but she did not pee until we arrived at the destination.

So I’m putting this out there, looking for any feedback from people that took their pets on flights.

I’m subscribed to Google Alerts for the keyword Plone, so whenever a new article or page mentioning Plone get’s picked up by Google, I get an email alert.

Today, I got an alert from an article published by Burlington Free Press. The summary in the email alert had the following text:

Northfield teen clocked at 104 mph while talking on cell phone
BurlingtonFreePress.com – Burlington,VT,USA
… driving 104 mph on Interstate 89 told police she was unaware they were
trying to stop her because she was talking on her cell plone, state police
said. …

http://www.burlingtonfreepress.com/apps/pbcs.dll/article?AID=/20080617/JS02/80617032

See all stories on this topic:
http://news.google.com/news?hl=en&ncl=http://www.burlingtonfreepress.com/apps/pbcs.dll/article%3FAID%3D/20080617/JS02/80617032

Notice the text says ‘cell plone’. Clicking on that link though tells you the article doesn’t exist anymore. If you click on the second link the article shows up and it’s published under a different url, which probably means someone was quick to detect the error, correct and re-publish the article under a different url. Not quick enough for Google’s indexing system though, which was able to index the article before the correction. If you search Google for “cell plone” the original article shows up as the 5th link right now. Unfortunately, the link to the ‘cached’ version of the page does not return the original page.

me: i mean, i had made a list of things already

Alexander: yup, but I’m sure there are more

me: those are the high-level yeah
for example, you can run with the python security policy
implementation, so that’s one thing less
acquisition needs to be ported though, or at least faked :)

Alexander: what about the __parent stuff that just landed in 2.11 (or
was it trunk?)

me: that’s implemented in Acquisition yeah
ExtensionClass, Acquisition and persistence are the 3 top modules
oh, BTree is a nasty one
probably better off trying to go to a non-ZODB based Zope by that time

Alexander: yeah, I suspect we should ditch the ZODB if we want to be
on App Engine

me: at the same time, there’s this project about porting Zope to Jython
if that’s successfull, it should run on pure python too
or maybe not, depends on which way this student goes

Alexander: right, the App Engine concerns are more than just what runs
as pure Python, though :)
database, memory usage, etc

me: but, what about the relstorage backend?
idea

Alexander: that’s why I included Martijn ;)

me: ok
so, yeah, those are my ideas
can’t think of much else

Alexander: ok
that’s a great start, thanks
now make sure the email or blog post covers the additional thoughts ;)

me: maybe the DirectoryViews stuff
the filesystem access is restricted right?
but i guess you can read files just fine?

Alexander: I have no idea :)

me: oh, k
number of files would be a problem
we should have all products running off zipped eggs by now
that would reduce the amount of files
but unfortunately no one worked on that

Alexander: I have to run, but feel free to continue in email ;)

me: ok

Alexander: trunk of Plone is mostly eggs, no?

me: but nothing is ready to load files off zipped eggs

Alexander: I see

me: i believe mcdonough did some work on that

Alexander: ok, see you later :)

me: ok
zcml would need to grow support for zipped eggs too

If you have more ideas, feel free to comment.

I am amazed to see the progress he and the folks helping him had so far. This is definitely all that I dreamed for when I started with the idea in January 2006. It is great to see that even though ideas take a little longer to get implemented in the Plone community that they do not simply get abandoned, but there’s always people willing to pick up an idea and turn it into reality.

Many thanks for Tarek for all of his work. Once this gets rolled out into the new plone.org it will make the life of us developers so much easier when making releases that we will ask ourselves “how could I live without this for so long”.

How would that be possible you ask? Well, a couple things are required.

The Repoze guys have Plone running as a WSGI app, AFAICT. So the hosting part is pretty much settled. You just deploy an app that sets up a Repoze WSGI App.

Then comes the storage. Plone, being based on Zope, uses the ZODB. But the Google App Engine doesn’t allow writing to the filesystem. The solution? Having a RelStorage backend that uses the DataStore API.

The final step would be getting rid of the C extensions in Zope, and having Zope run in Pure Python. Fortunately, there’s a student application for this year’s Google Summer of Code project that intends to port Zope to Jython! That should help with this last step by providing Pure Python implementations of the C extensions, if it gets approved.

I am really excited by the possibilities that this opens up. And would love to see someone pick up this project and turn it into reality.

As can be seen from the referenced paper, web technologies make some things just way too simple to hack around.

On a unrelated note, call me luddite, but I really think moving our life to the cloud presents way more unforeseen threats than our little brains can imagine.