Matt wrote:
I've heard various statements that a product which sets up a site
should use a base profile. I have interpreted this as define all
types, all workflow, all toolsets, all skins etc into the profile of
that product. For example for plone, one would copy
CMFPlone/profiles/default and work from there, filling out the profile
to include other 3rd-party products that you want in your custom site.
Is this the right interpretation?
What is the argument for a site product to use a base profile?
Actually, what is a base profile? Is it not just a particular profile
that happens to have a typically replete set of import export steps
that cover the import export handlers of GS as it ships?
here's my understanding. this is not necessarily the original intention, nor
is it necessarily everyone's understanding, but it is IMO a sensible way to
think of things, and it is largely informed by a number of discussions w/ the
GenericSetup team at the BBQ sprint (you can see who was on this team at
http://www.openplans.org/projects/bbq-sprint/generic-setup-report):
base profiles represent an entire configuration. a base profile should be
applied at site creation time, whether or not there are any extension profiles
provided. it is dangerous to change the base profile for a given site (doing
so would wipe out the set of registered import steps, and importing the
profile would clear out existing site configuration), and indeed you should
rarely need to do so. a given site can only have a single base profile at any
given time.
extension profiles, as you might guess, extend base profiles. they are not
enough to define an entire site's configuration. they do not need to
redeclare import steps that are already defined in the base profile, even if
they contain configuration related to those steps. they need only declare
import steps if they introduce new steps that are specific to themselves. it
is possible and often desirable to have several extension profiles
simultaneously applied to a given site.
ideally, extension profiles are purely additive, i.e. they introduce new
configuration, but they don't modify existing configuration. while it is of
course possible for an extension profile to change configuration that is set
in the base profile, this is somewhat risky, as it muddies the responsibility
for that piece of configuration. re-importing the base profile may end up
reverting the config to its original state, negating the impact of the
extension profile.
it is true that a number of Plone products are defining extension profiles,
and that the application of these extension profiles to the site is how you
would "install" these products. recent versions of the quickinstaller will
automatically list extension profiles of a certain semantic as products to be
installed, and will list them alongside products that have a more traditional
Install.py module with an install function. for the most part i think this is
fine. there is, of course, a slight risk involved if a product wants not only
to add new configuration, but instead wants to tinker with existing
configuration that was set by a different profile, as described above. this
is the biggest unresolved issue around using extension profiles to install
products, IMO.
note that snapshots are necessarily equivalent to base profiles. a snapshot
contains the configuration for the entire site, and thus is meant to be used
as a base profile would be used. similarly, an exported profile is a base
profile. it is possible, however, to export only a single export step, after
which one could remove certain parts of the exported config by hand to get
something suitable for use in an extension profile. i do this all the time
for workflows, for example.
it may be argued that extension profiles were never meant to be used as a
means for product installation. so far, however, this strategy has proved
effective, and IMO is considerably nicer than what we had before. whether or
not it was the original intent, it has become a valuable use case, and i
suspect will continue to grow in usage.
-r
_______________________________________________
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
