[Product-Developers] [ANN] New simplified product skeleton for Plone

Dylan Jay djay at pretaweb.com
Wed Mar 21 08:29:53 UTC 2012

On 21/03/2012, at 7:12 PM, Martin Aspeli wrote:

> Hi,
> On 21 March 2012 04:50, Mikko Ohtamaa <mikko at opensourcehacker.com>  
> wrote:
> Hi Martin & co.
> On Tue, Mar 20, 2012 at 20:35, Martin Aspeli <optilude 
> +lists at gmail.com> wrote:
> On 20 March 2012 17:15, Mikko Ohtamaa <mikko 
> +plone at redinnovation.com> wrote:
> Hi,
> I have created a new Plone add-on code skeleton based on Plone 4.1,
> five.grok:
> https://github.com/miohtama/sane_plone_addon_template
> It is not based on any template engine: just clone and go.  Tries to  
> be as
> minimal as possible.  Instructions provided.
> Cool ;-)
> Did you have a look at the 'plone-customizations' egg provided by  
> plone-devstart? Wondering if it serves a somewhat similar purpose.
> I checked out plone-customizations egg and some other stuff which  
> was pointed out for me on this mailing list and elsewhere.
> I was just wondering if the following goals where possible to  
> achieve the minimum barrier of entry for new Plone developers
> * plone_devstart serves as a development start-up buildout, but  
> eventually these changed should be merged to unified installer so  
> that no separate "installer" for developers are needed. Even in the  
> worst case we should ask people to run "cp development.cfg  
> buildout.cfg" or similar. I don't see we have other barries besides  
> by simply making the default buildout runnable without virtualenv  
> (buildout is broken...). We know what must be done to accomplish this.
> We had that debate in the other thread, but there are other  
> environment issues that trip people up (e.g. wrong Python, missing  
> libraries) that we need to check too. Maybe buildout could check  
> those (from an extension) of course.
> * sane_plone_addon_template, plone-customizations etc. efforts will  
> be merged in one codebase which is documented in collective-docs.  
> This add-on could be available also in unified installer, in not  
> installed state. collective-docs example code could rely that you  
> have this add-on present, it's views.py layout is fixed and so on.
> The one problem is that there are many equally valid variations on  
> what people want, and trying to produce on skeleton with 'all'  
> examples makes the skeleton complex. You chose the five.grok route,  
> for instance; you also chose to include CMF skin layers. I haven't  
> registered a portal_skins layer for *years*, preferring z3c.jbot and  
> views.
> * there is only one Plone add-on code skeleton, unlike separate  
> Zopeskel templates. This code skeleton will have "features" you can  
> enable, like content types. E.g. the default  
> sane_plone_addon_template comes without base file content.py, but  
> you could throw it in a folder after which you can macro create more  
> content types using a simple Python command which copies in files  
> and renames them if needed. Currently it is great mess because you  
> need to create one product for content types, one for themes, so on.
> I think for 'mature' use cases, it makes sense to separate into  
> packages, but I agree that it's better to have them co-located for  
> simple use cases.
> The other thing plone-devstart chose to do, which I think makes  
> sense for 'new' users, is to not worry about egg namespaces or  
> custom naming at all. Every user of plone-devstart could have an egg  
> called 'plone-customizations', and it'll have the same name if the  
> use plone-devstart on ten projects. They will never release that  
> egg. They'll deploy it, from a tag or trunk, straight out of source  
> control.

With collective.hostout they don't even need the step of deploying out  
of source control. That would require them to setup their deployment  
environment, install the source control etc on the production server  
etc. Instead hostout packages and uploads their development eggs for  
them directly into the remote server buildout cache, as well as  
setting up the remote server with the buildout they are using. No  
source control required.

bin/hostout host bootstrap   <- to get the server ready for buildout

bin/hostout host deploy <- to replicate their buildout to the remote  
server + upload packages.

BTW: I think the plone-customizations idea is a great simplification  
for beginners. It might create bad habits but it's one less thing they  
have to learn upfront which is a big plus.

I'd suggest hostout could be a good addition to something like devstart.

> That's not how professional Plone development shops choose to work,  
> because they have more complex demands. But it's perfectly good  
> enough for most people, and it's not that hard to learn how to  
> manage source code more effectively once you've learned how to write  
> the source code in the first place.
> * In the optimal situation no code generators should be used with  
> Python and operations like adding a new content type should be a  
> dropping new class in content.py file (think Django). However, I  
> don't see how we are going to achieve this in long run with the  
> current Plone codebase which is mess of ZCML, .py and GenericSetup  
> XML registrations
> I actually think code generators tend to hinder adoption and  
> understandability more than they help. Better to have well- 
> documented, cross-referenced examples ("You also need to  
> update ...") and work to simplify the stack (think Dexterity, and  
> its use of martian).
> * Let's deprecate Paster + ZopeSkel, or any other related templating  
> solution, as I believe I can achieve the same or better results with  
> a bunch of files, string replacement and 250 lines of barebone  
> Python script. They only make things unnecessary complex and not  
> maintainable.
> I think we need to thread carefully here. I agree that simple is  
> better. But ZopeSkel has served us well. I think there will be a  
> need to instantiate different things. We won't come up with one  
> skeleton to serve all needs, so having some way to manage deployment  
> of skeletons and consistency is useful.
> * I will disagree with everyone else what kind of code skeleton file  
> layout etc. we should we have, but eventually I am right :)
> I think we should aim for simplicity, first of all.
> Martin
> _______________________________________________
> Product-Developers mailing list
> Product-Developers at lists.plone.org
> https://lists.plone.org/mailman/listinfo/plone-product-developers

More information about the Product-Developers mailing list