One of the outcomes of the ZopeSkel BBQ sprint was a set of
proposals regarding the future of the zopeskel project. Many of
these proposals are sweeping enough in their scope that those of us
in attendance at the sprint felt that the input of the community
would be required before we moved forward enacting any of them. I'd
like to take this opportunity to lay these proposals out in a public
forum for discussion:
Splitting ZopeSkel into Egg Packages
:Date: 5 Oct 2009
ZopeSkel is currently a single egg, "ZopeSkel". It contains templates
- scripts/utilities that are not template specific
- basic nested Python packages, without any Zope/Plone bits
- Basic Zope product/buildout templates
- Plone product/buildout templates
- Silva buildout template
- Code for the "local commands" system
- Local commands for Plone products
We propose to divide ZopeSkel into separate packages & eggs:
Local commands system, scripts/utilities
``zopeskel.zope`` *(will depend on zopeskel.base)*
basic_zope template and Zope-only buildouts
``zopeskel.plone`` *(will depend on zopeskel.zope)*
all plone templates/buildouts and local commands for Plone
``zopeskel.silva`` *(will depend on zopeskel.zope)*
Since there is a great deal of documentation that tells users to
"easy_install ZopeSkel", we need to make sure there is still a package
called this that provides the assumed components.
Therefore, we will keep a ZopeSkel egg, but have this provide no
code/packages-- it will only exist so that it has setuptools
pull in zopeskel.base, zopeskel.zope, zopeskel.plone, zopeskel.silva.
Therefore, people following this documentation will get the "full"
Curently, ZopeSkel can be a bit of magnet for recipes that may not be
widely needed by all members--there are non-Plone users of it that
want to get all of the Plone recipes, for example. In the future, they
would be able to ::
to just get the Base/Zope parts.
With additional adoption of ZopeSkel, we anticipate other communities
(Repoze, etc) wishing to add templates, and would prefer to avoid an
overly- long list of packages. This is especially important as, at
the Plone world, ZopeSkel is increasingly used by
integrators/non-developers, and a long list of packages unrelated to
needs is confusing.
In addition, this will subtly reinforce to people that there *can
party packages that add templates. Larger institutional users of
Python/Zope/Plone/Silva may find it beneficial to write their own,
customized templates (the author of this document already does, for
example); however, that this is possible is slightly obscured by the
that we ship only one monolithic system with all the recipes in it.
1) Change the imports and entry points inside of ZopeSkel to match
these new package names; for example, changing "plone.py" to
import the BasicZope class as
"from zopeskel.zope.basic_zope import BasicZope".
2) Adding imports to zopeskel/__init__.py to import everything into
namespace that was previously there. This will ensure that 3rd
templates that made assumptions like "from zopeskel import
will still work.
3) Break packages into separate eggs and check into new repository.
4) Empty ZopeSkel package and add setuptools requires so that this egg
now installs all the new eggs.
Given that ZopeSkel has a wider audience than just Plone, we don't
make sense to move it into the plone repository. However, it also
seem right to leave it in the collective--here, it has become a
individual, not-well-organized changes that run counter to the
that it be a stable, best-practice product.
We recommend creating a new repository, "zopeskel", which would
zopeskel packages. This would allow us to grant svn access to people
without sharing core plone access, and would discourage collective-
With thanks for your attention, and for any comments and discussion,
Webmaster, Lead Developer
Department of Radiology Web Services
University of Washington
School of Medicine
Work Phone: (206) 616-1288
Cell Phone: (206) 708-9083
Pager: (206) 559-2306
ZopeSkel mailing list