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
[email protected]
https://lists.plone.org/mailman/listinfo/plone-product-developers
--
Alex Clark ยท http://pythonpackages.com
_______________________________________________
Product-Developers mailing list
[email protected]
https://lists.plone.org/mailman/listinfo/plone-product-developers
