[Zope-CMF] Re: Multiple GS profiles per product
Tres Seaver, on 2008-05-19: >> Can you add a ticket for this last issue? > > I'm assuming that you mean against QI? Because I see nothing which > needs changing in GS here. Correct. -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "This is your day, don't let them take it away." [Barlow Girl] ___ 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
[Zope-CMF] Re: Multiple GS profiles per product
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 possible. >> 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/Install.py 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)Install.py files. I >> moved those out of the way and restarted. > > Why did you remove Extensions/Install.py? 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/Install.py. 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/Install.py nothing should be read from the profile database. > > Can you add a ticket for this last issue? Yes: http://dev.plone.org/plone/ticket/8142 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 | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "This is your day, don't let them take it away." [Barlow Girl] ___ 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
[Zope-CMF] Re: Multiple GS profiles per product
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: > 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 ;) > >> 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/Install.py 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. > >> 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)Install.py files. I >> moved those out of the way and restarted. > > Why did you remove Extensions/Install.py? 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. Perhaps that supports QI better, but killing off *all* impoerative installation / configuration is a worthy goal (and one which has been neglected for far too long). >> 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. :) > >> In the case of eXtremeManagement, the day is saved because it still >> has an Extensions/Install.py. 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/Install.py nothing should be read from the profile database. > > Can you add a ticket for this last issue? I'm assuming that you mean against QI? Because I see nothing which needs changing in GS here. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIMMa++gerLs4ltQ4RApPZAJ95rSHFd4LWPKFwwPlKxWqNOqSkHQCgslKQ FdM1ddp9IkRE4jA9a30sP7o= =OAuv -END PGP SIGNATURE- ___ 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
[Zope-CMF] Re: Multiple GS profiles per product
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 ;) 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/Install.py 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. 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)Install.py files. I moved those out of the way and restarted. Why did you remove Extensions/Install.py? 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. 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. :) In the case of eXtremeManagement, the day is saved because it still has an Extensions/Install.py. 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/Install.py nothing should be read from the profile database. Can you add a ticket for this last issue? Hanno ___ 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
[Zope-CMF] Re: Multiple GS profiles per product
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Maurits van Rees wrote:
> Some observations here with a few questions sprinkled through.
>
> For Plone we at Zest Software made eXtremeManagement (affectionately
> called xm), a project management tool. See
> http://plone.org/products/extreme-management-tool
>
> For upgrading from Plone 2.5 to 3.0 I made an "upgrade profile":
> basically just a regular extension profile that is not meant to be run
> directly from the portal_quickinstaller or portal_setup but that is
> only hooked up to an upgrade step like this:
>
> def from_plone25_to_30(context):
> context.runAllImportStepsFromProfile(
> 'profile-Products.eXtremeManagement:eXtremeManagement-30-types',
> purge_old=False)
>
> It removes some actions from some portal types, which seemed handy to
> do in a GS profile instead of manually coding some python. Works fine
> actually. This is on Plone 3.0 with CMFQuickInstaller 2.0.4.
>
> Note that for GS upgrade steps you do not really need "upgrade
> profiles". That was just my understanding/expectation of how to do
> upgrade steps at the time.
Sees reasonable, although I should say that I don't use the "upgrade"
machinery in GS at all.
> But: along comes Plone 3.1.1 with CMFQuickInstaller 2.1.4. This has
> slightly different handling of GS profiles. In this case when
> visiting the portal_quickinstaller in the ZMI it does not seem to care
> much for the Extensions/Install.py, it finds the two profiles (the
> "upgrade" profile and the default profile) and picks the first one it
> finds and print its name in the list of installed/installable
> products. So the QI now gives eXtremeManagement the dopey title of
> "eXtremeManagement types fix for Plone 3.0", which is the title of the
> upgrade profile.
This is a bug: QI should probably be displaying *all* extension
profiles registered for the site root interface, rather than trying to
bless one per product.
> 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"?
> For reference, this is info from the two profiles I now have:
>
> [{'description': u'eXtremeManagement types actions fix for Plone 3.0.',
>'for': Products.CMFPlone.interfaces.siteroot.IPloneSiteRoot>,
>'id': u'Products.eXtremeManagement:eXtremeManagement-30-types',
>'path':
> u'/home/maurits/buildout/test/products/eXtremeManagement/profiles/30',
>'product': 'Products.eXtremeManagement',
>'title': u'eXtremeManagement types fix for Plone 3.0',
>'type': 2,
>'version': '1.5.2'},
> {'description': 'Profile for Extreme Management',
>'for': Products.CMFPlone.interfaces.siteroot.IPloneSiteRoot>,
>'id': 'eXtremeManagement:default',
>'path': 'profiles/default',
>'product': 'eXtremeManagement',
>'title': 'Extreme Management',
>'type': 2,
>'version': '1.5.2'}]
>
> The first one is the upgrade profile, only meant to be used via the
> Upgrades tab in portal_setup. The second one is the default profile
> that I want to have available in the quick installer.
>
>
> 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)Install.py files. I
> moved those out of the way and restarted. On Plone 3.0 everything
> seems to go fine: the name in quick installer is 'Extreme Management'
> and installing it does everything it needs to do, using the default
> profile. This is because the upgrade profile is not found, due to a
> slightly different implementation of the getInstallProfile method.
>
> Now, on Plone 3.1.1 (QI 2.1.4) with a fresh zodb the QI lists that
> strange name of the upgrade profile instead of the name of the default
> profile. And indeed when installing it only that upgrade profile is
> executed, not the default profile.
Proposed changes to QI aren't exactly in scope on this list.
> 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.
Yes, I use multiple profiles.
> Question 3: Should we encourage programmers to only use one profile,
> presumably simply in a directory named 'profile' by default?
No. The name 'default' should *definitely* not be majyk.
> In the case of eXtremeManagement, the day is saved because it still
> has an Extensions/Install.py. 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.
>
> Meanwhile on trunk (and on the 1.6r
