[Product-Developers] [ANN] New simplified product skeleton for Plone
Alex Clark
aclark at aclark.net
Thu Mar 22 00:54:03 UTC 2012
Hi
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:
-
http://docs.pythonpackages.com/en/latest/advanced.html#buildout-easy-install-vs-virtualenv-pip
(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.)
Alex
>
>
> --
> 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