Check out ILRT PyPi

ILRT now has its own python code repository and general documentation server at http://pypi.ilrt.bris.ac.uk

So some of the more technical posts from this blog have been moved to the HowTos there.

Any ILRT python code should have its packaged documentation this is now checked out from svn to an eggserver folder on devbox and punted up into web pages via a cron job.
I will look at adding the dump of these to the windows file share as well, so code specs etc. can be tied to release tags and round trip within the code to svn to eggs to the repo web pages to windows share text docs (editable in Word or whatever).

Along with that the repo can hold 'manuals' eg. code club presentations etc. and other bits and pieces. Plus FAQs a useful place to add any quick hints or tips - certainly if you ever waste an hour working out some undocumented thing that in itself only takes 5 minutes, please always add it as a FAQ.

Sorry the actual server is a bit bare plone, it could probably do with being made more like http://www.coactivate.org (a free basecamp stylee plone used for open source project planning)
Or possibly use sphinx, or one of the more documentation centric python tools?

NB: The server is only accessible within the University. Internet development team members can log in via their standard zope accounts if anyone has the urge to edit anything (hopefully!)

Reading anyone?

After springing a few hundred books into the skip today, I thought it makes sense to add reviews of books that we have just read.
So that others in the team can judge whether they are worth a gander. Over the last 9 months I have read the following work books.

My january laying season is over

Ok just sneaked in one more egg to pypi before the end of the month.

ilrt.migrationtool

... bringing ILRT up to a grand total of four packages in pypi.

I doubt I am likely to have the space (or inclination) to do three eggs in one month again ... unless we get some really full time UOBCMS migration funding.

This particular egg adds the controlled release functionality that was developed in a more specific manner by Dom for the UOBCMS. But this time it can be used for any site, where the migrations are added to the sites theme egg. In addtion it is all rewritten the zope 3 way, and bundles a sub-tool that migrates content's workflow.

All required for changing the workflow used by the production ECU site.

... OK should be finished with plone for a little while (apart from plone2/3 site support) ... time to do a bit of django ...

... egg number 3

Yep put out another one ... this one gives roughly the same workflow as we have used with
in the past with BaseCMS and UOBCMS ...
http://pypi.python.org/pypi/ilrt.formalworkflow

NB: learnt a couple more lessons ... added to instructions below ...
1. remember to register from a fresh svn checkout (dont want .pyc from a instance)
2. use python2.4 since python breaks when it encounters decorators
3. make sure tag_svn_revision is set to false
4. your download counter gets reset every time you replace a file even if they are called the same ... so try not to replace files except if there is a glitch when testing the install from release - at release time ... this is good practise anyhow since even minor textual changes mean its not really the same release.
... however that doesnt mean you cant always re-edit documentation ... just do
python2.4 setup.py egg_info
python2.4 setup.py register
5. Finally remember you might as well edit setup.py so that it pumps in README, HISTORY and TODO into the long description field.

Another ILRT egg released

Finally got around to finishing and releasing the egg for generating content / plone sites matching different profiles - e.g. intranet, public etc.

http://pypi.python.org/pypi/collective.contentgenerator ... our second cheeseshop / plone.org release and the first that I acted as release manager for.

Technical gotchas regarding releasing code

Do all your metadata in the right places first then use setup tools to regenerate the metadata files.

So my recommendation is start at the top with setup.cfg which should release tag changed from dev to nothing and svn from true to false ... or else you get _rSVNnumber appended to your release versions.
Next setup.py add your metadata here (classifiers can be found on the pypi form dropdown) ... then make sure the version you specify in setup.py is copied to the one in egg.name/version.txt
Next get your final text ready in README.txt and HISTORY.txt (using restructured text)
Now run
> python2.4 setup.py egg_info
this regenerates your.eggname.egg-info/PKG-INFO and the other metadata files. So you can check them before uploading.
Finally you cpuld upload PKG-INFO to pypi by hand but is easier to do it all in one fell swoop via setuptools register.

> python2.4 setup.py register sdist bdist_egg upload

(the sdist makes a source tarball and the bdist_egg and egg)

If you really need to do final tweakings ... via the pypi web form ... you can do so but you will then have to go to the generated PKG_INFO link on pypi and copy and paste the results back into README.txt etc., rerun egg-info and re-upload your egg tarball ... I did all that at first and then realised that was a really bad idea!

Lastly all you need to do is go through the whole process again via different web forms on plone.org ;-)
... though I think this is being addressed?

* Oh and one final bugbear ... where do you set platform in the metadata?

Plone performance sprint

I (Ed Crewe) took part in the Bristol Performance sprint - or at least the first two days of it.
The project site details topics explored.

Key areas for performance increase looked at were:

ZODB storage paradigm - Lawrence Rowe et al.
ZCatalog querying (for set ops), splitting and queuing. - Jarn people
Chameleon - This precompiles page templates into python for execution speed improvements ... the guy who wrote it and the ZPT implementaion ... Malthe Borsch was looking at improving its effects.

Benchmarking and load testing

Alongside this there was the need to establish a testing framework and benchmarks to test against. The aim being to have a set of standard content profiles for realworld sites ... along with an easy to install load testing framework. Hence provide a set of standards with which to compare performance over time and code versions.

We decided to go for funkload over jmeter to reduce cross language dependencies and make the load testing code more accessible to plone / python developers. A recipe / buildout and set of test plans is being developed to make the installation of a standard load test benchmark available.

My part of the work was to do the content profiles ... so there is now an egg in the collective that generates content according to various options to provide a set of content profiles ... currently just going with small intranet and large public sites. Details in the README.

Hopefully collective.contentgenerator will be finished off within the next month or so, along with the load test recipes. They could then be used for a standard performance report on plone.org as versions come out.

NB: Also punted up the performance fix for placeful workflow for the latest version in terms of patch files.

World plone day 2008

I am taking part in a meeting of plone developers in Bristol for world plone day.

I will be giving a couple of lightning talks

A glimpse of what we did with plone for the University of Bristol CMS

Egg start - how and why I started contributing back to open source in python and plone

... so please come along ... it is only for an hour or so tommorrow lunchtime.

----------

Here is the video of the event.