[Zope-CMF] Re: Base and Extension profiles

[Rob Miller]

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