Just a bill to announce the first release of Nagare that use stackless Python.
If you want to test it you can try the Full Demo
If you want to install it you can follow the Quick Start Guide

As Open Source developer I’m concived that we are developping on the best tools ever created (early friday) and I’m using a proprietary IDE… but writen in Python: Wing IDE.
 
With this IDE you need only two operations to make it understand a new buildout:

• add your bin/instance (bin/zopeinstance or bin/zeoclient) in your project via the project Panel
• once it is done select it and right click on it to activate it as ‘main debug file’

 
Then wait that wing update the python path for you and enable the autocompletion for your whole project. That’s magical, I love it!

Thanks to Lennart to ask the good question on wing-users mailing list and to Martijn Pieters to give us this excellent recipe.

It would be cool is there’s such recipe fir IDE in the new documentation section on plone.org.

1. Product or framework

Harry Porter: Is Plone a framework or a product ?

Encolpe: Both, Sir.

HP: Then why I cannot see which part of Plone is a framework, and which one is the Plone product ?

E: Eh !

E: Hum…

E: I guess there’s something wrong in the architecture. But there no fatal issue.

HP: OK, then where the base content implementation ?

E: Archetypes propose schema, filed and widget implementation with some basic implementation for the content object (unit, folder too).

HP: Now what do ATContentTypes ?

E: … some advanced implementation of content objects. I guess what you want me to say: basic implementation of content object should move from Archetypes to ATContentTypes to make a real separation between how a content object is stored and how it is displayed with additional functionalities.

HP: I wasn’t thinking so deep. I suppose that replacing Archetypes by something else would be easier if you choose this design.

HP: I tested NuPlone theme product and it was cool. But why the basic Plone theme cannot be separate from the CMFPlone product ?

E: Here I guess you reach the root of the problem. CMF have two base products to separate the framework from its basic implementation: CMFCore and CMFDefault. Plone doesn’t have such a trick: the CMFPlone product does both. I guess it comes from its will to be usable out of the box with only one click. To anwser to your original question split Plone in two products will not be enough to have a specific product for the basic theme: this one must be integrated in the default Plone product implementation then other Plone theme can be relied on it.

HP: Something hurt me recently when I discovered that CMFCore contains no skins directory.

E: We reach again a design choice and you may find another examples in Plone 3. The Plone architecture design must be a critical point in Plone 4 more than what’s the new cool feature we will add.

2. Out of the box versus ready to be customized

HP: Now, imagine that I’m a newbie in web and I want my website with cool theme. Where can I find themes for Plone and how can I customize it ?

E: You want site for Plone theme ?

HP: Not really. I want interactivity. Browse themes in a site (plone.org or somewhere else), then download an archive, put it in the PMI ad finally restart Zope (do we really need this step ?). Now I can choose my theme in the PMI. I want to be able to choose and use a theme like I do with my desktop theme.

E: Wooh. And you think that should be enough ?

HP: No.

E: …

HP: I want to be able to customize it simply. Without learn python or any template language. I just want an editing tool for viewlet and for basic stylesheet properties without having to go in the ZMI or to know an hide feature.

E: Only that ?

HP: If I can only learn HTML, CSS to customize my theme it really would be cool. Imagine a theme community around Plone.
E: It’s far from big projects I lead today, but I can see the benefit for the whole Plone community.

HP: It is like having Plone translated in the 40 most important languages: the goal is to raise interest in Plone with basic stuff to finally create business.

E: But you can use Plone out of the box right now and add tons of functionalities.

HP: Finally, i’am just an user, may be something like an advanced user, of system softwares. I don’t want to know anything around buildout, it’s to low level for me. Like for eclipse plugin I want to be able to browse plonepi within the PMI and choose a functionality or a product to add. Then plone should make an easy_install for me. I don’t care if it use zc.buildout in backend. I want my customization to be transparent.

E: Oh. You want Pypi integrated in Plone.

HP: Something like that, yes.

E: And if the egg that Plone download and install for you breaks the site, what shall Plone do ?

HP: In an ideal world it should run unittests and functional tests before to install it, shouldn’t it ?

E: Yes, but test coverage isn’t the priority in lots of projects. We need some code reviewer to elect some products and something to declare possible conflicts between eggs.

HP: It’s your work, not mine.

E: I can see the point. Is that enough for today?

HP: Yes. I may have some other questions or needs tomorrow.

E: And tomorrow is an other day.

Les distributions GNU/Linux usent et parfois abusent de python comme langage de script pour la configuration du système. En contrepartie il devient difficile d’utiliser easy_install sans casser le système. Il se peut aussi que certains logiciels python est une liste de dépendances tellement longue qu’il soit impossible de les installer tel quel dans le système avec easy_install. Pour éviter ces écueils, plusieurs parades ont été mises au point et la plus aboutis est sûrement virtualenv.

Les eggs des modules comme python-ldap ou Python Imaging Library sont très dépendants du systèmes et demandent des installations particulières selon les plateformes (PILwoTK ne fonctionne pas sous win32 par exemple). D’autres eggs comme gaphor ou i18ndude demandent quasiment une installation séparée. Pour ces derniers il est possible de sans toucher au Python du système.

Pour commencer il vous faudra choisir sur quelle version de python vous souhaitez travailler :

# easy_install-2.5 virtualenv

ou

# easy_install-2.4 virtualenv

Ensuite vous aller créer une boîte pour votre python :

$ virtualenv --no-site-packages monprojet cd monprojet$ ls

bin         lib

# voici une commande toute prête pour modifier le PATH

$ source ./bin/activate

(monprojet)$ which easy_install

/home/encolpe/monprojet/bin/easy_install

(monprojet)$ which easy_install-2.4

/home/encolpe/monprojet/bin/easy_install-2.4

(monprojet)$ which python2.4

/home/encolpe/monprojet/bin/python2.4

(monprojet)$ which python

/usr/bin/python

À partir de maintenant vous pouvez utiliser easy_install dans votre répertoire sans craindre d’interaction avec le système.

L’installation des modules python demande une précaution: être sur d’utiliser les version 64bits des bibliothèques C sous peine d’avoir de drôles d’erreurs absolument intraçables.

La solution est de déclarer le chemin vers /usr/lib64 explicitement pour lors des l’édition des liens:
export LD_LIBRARY_PATH=/usr/lib64

Exemple avec PIL

Version installé avec libjpeg-devel_32, zlib-devel_64 et freetype-devel_64. A la fin de l’installation on vous dit ça:

--------------------------------------------------------------------
version 1.1.6
platform linux2 2.4.4 (#2, Jul 17 2007, 10:05:5
[GCC 4.1.2 20070115 (prerelease) (SUSE Linux)]
——————————————————————–
*** TKINTER support not available
— JPEG support ok
*** ZLIB (PNG/ZIP) support not available
*** FREETYPE2 support not available
——————————————————————–

Le support jpeg est le seul installé… du coup l’intervenant installe les versions devel_32 pour les autres.

Vous noterez qu’il n’y a aucune référence au 64bits dans les infos sur la plateforme.

--------------------------------------------------------------------
PIL 1.1.6 BUILD SUMMARY
——————————————————————–
version 1.1.6
platform linux2 2.4.4 (#2, Jul 17 2007, 10:05:5
[GCC 4.1.2 20070115 (prerelease) (SUSE Linux)]
——————————————————————–
*** TKINTER support not available
— JPEG support ok
— ZLIB (PNG/ZIP) support ok
— FREETYPE2 support ok
——————————————————————–

toto@webtest:/tmp/Imaging-1.1.6> /usr/local/bin/python2.4 selftest.py

*****************************************************************

Failure in example: _info(Image.open(”Images/lena.jpg”))

from line #24 of selftest.testimage

Exception raised:

Traceback (most recent call last):

File “./doctest.py”, line 499, in _run_examples_inner

exec compile(source, “<string>”, “single”) in globs

File “<string>”, line 1, in ?

File “./selftest.py”, line 22, in _info

im.load()

File “PIL/ImageFile.py”, line 180, in load

d = Image._getdecoder(self.mode, d, a, self.decoderconfig)

File “PIL/Image.py”, line 375, in _getdecoder

raise IOError(”decoder %s not available” % decoder_name)

IOError: decoder jpeg not available

1 items had failures:

1 of 57 in selftest.testimage

***Test Failed*** 1 failures.

*** 1 tests of 57 failed.

Là, l’intervenant commence à se ronger les ongles et à chercher l’entrée de la 4^ème dimension.

Il fouille le net et fini par tomber sur un message d’espoir:

http://osdir.com/ml/python.image/2006-05/msg00029.html

Évidemmement il n’y a aucune référence à ce point dans la documentation de PIL.

Donc, il faut installer les versions -devel_64 des bibliothèques et déclarer LD_LIBRARY_PATH dans votre shell:

toto@webtest:/tmp/Imaging-1.1.6> /usr/local/bin/python2.4 selftest.py
57 tests passed.

Que du bonheur.