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

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 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.


Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to