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

Alex Clark aclark at aclark.net
Thu Mar 22 00:54:03 UTC 2012


On 3/21/12 5:05 AM, Mikko Ohtamaa wrote:
>         * 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.
> z3c.jbot is preferred template customization approach, as per documented
> in the instructions. However touching portal_skins is still required for
> some .py and .cpy actions, e.g. overriding login destinations. If you
> have not touched portal_skins layers for years you have been quite lucky
> :) But this is an implementation detail which can be made an optional
> feature people can later enable as you are right and luckily the number
> of use cases where you need to touch portal_skins is shrinking.
>     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.
> Also this holds true for youraddon which is an egg itself and currently
> available in any buildout by simply git clone + buildout.cfg update. To
> make the development path to "professional egg" easier there exist a
> Python script called personalize.py which can later rename the egg if
> needed. personalize.py script will also clean up stock examples and
> ponies from the source code.
>     * 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.
> ZopeSkel has served us well, but does not serve us well currently.
> Templates are outdated. No one is maintaining them. Code base is mess
> and not accessible by external developers. The development is stagnated.
> The future is open. It's time to retire ZopeSkel. RIP ZopeSkel.

See my generic tools rant:


(I don't believe throwing other tech under the bus is particuarly 
helpful, though I understand the frustration and am often tempted to do 
the same thing. Everything was new and shiny once and it's easy to 
support & use a tool during that phase. Much harder to keep using that 
tool and help it through the more challenging times. Plone itself is a 
good example of a tool we all keep using because we are able to see the 
good through the bad.)


> --
> Mikko Ohtamaa
> http://opensourcehacker.com
> http://twitter.com/moo9000
> _______________________________________________
> Product-Developers mailing list
> Product-Developers at lists.plone.org
> https://lists.plone.org/mailman/listinfo/plone-product-developers

Alex Clark · http://pythonpackages.com

More information about the Product-Developers mailing list