Thanks for the comments, Tres and Hanno.

Hanno Schlichting, on 2008-05-16:
> Hi.
> Maurits van Rees wrote:
>> This is on Plone 3.0 with CMFQuickInstaller 2.0.4.
> I think you are on the wrong list here. QuickInstaller is a part of 
> Plone and not CMF and should be discussed on plone-dev. I'll give some 
> responses anyways ;)

Ah, I was thinking "It starts with CMF so I will mail the CMF list."
But the CMF-QI is in the plone collective indeed.  My bad.

Is anyone in CMF land using the CMFQuickInstaller without using
CMFPlone?  There are no imports from CMFPlone so it should be

>> Question 1: can I influence which profile is picked here?  Should we
>> add some code to the QuickInstaller.getInstallProfile(s) methods to
>> for instance prefer a profile with a name like "productname:default"?
> Picking the first profile from the arbitrarily sorted list of profiles 
> is obviously a shortcoming of QI. The main problem here is that QI uses 
> the product name as a primary key for all its operations and thus can 
> only really handle one installation record for one product. The whole 
> use of extension profiles as installation procedures is a bit of a hack. 
> What should really happen and which I'll do for Plone 4.0 is to remove 
> the support for Extensions/ and give up the one-to-one 
> relationship between products and installation records. What happens in 
> the end is that you apply configurations to a site - that can be as many 
> as you want with extension profiles. I just don't see a way on how to 
> move forward with this without a clear cut.

I'm interested in this as well.  If you need a hand in
thinking/coding/testing ping me and I'll see what I can do.

>> Now, I tested with eXtremeManagement 1.5.2, the latest stable release,
>> in case anyone wants to try it out (remember to add a Poi 1.1 bundle
>> too).  That release also has Extensions/(App) files.  I
>> moved those out of the way and restarted.
> Why did you remove Extensions/ This one is supposed to take 
> precedence over extensions profiles. In your case having one, which 
> installs the GS profile you want internally should work just fine.

I removed it for testing, just to see what would happen; no commits
were done, no bits in the collective were hurt in the process. ;-) It
was actually removed for real a while back, which still worked fine
for Plone 3.0/GS 1.3, but Jean-Paul added it back for other reasons.

>> Question 2: I am used to having a profiles directory in a product and
>> a subdirectory inside it named 'default'.  eXtremeManagement is the
>> only product I know that has a second profile next to it.  Are others
>> using more than one profile?  Well, CMFPlone does a few things here.
> Multiple profiles are common. I think I made the profiles/default thingy 
> the default value, when you don't provide one in ZCML, but that's all 
> the magic there is and should be.
>> Question 3: Should we encourage programmers to only use one profile,
>> presumably simply in a directory named 'profile' by default?
> No. :)

OK. :)

>> In the case of eXtremeManagement, the day is saved because it still
>> has an Extensions/  That is the installer that is actually
>> executed and it has some code to run the correct profile, including a
>> dependency.  The only hickup so far is that with the newer QI the name
>> of the other profile is listed instead of the default profile.
> That is a bug. I think someone added this code of taking the title from 
> the profile, shortly before the final and I missed to review it 
> properly. We should just revert those changes. If you have an 
> Extensions/ nothing should be read from the profile database.
> Can you add a ticket for this last issue?


I did not see a component that it would really fit for; I chose
'Upgrade/Migration' as in my mind that was the best fit.

I was so bold as to assign the issue to you. :-)

Maurits van Rees |
            Work |
"This is your day, don't let them take it away." [Barlow Girl]

Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to