Re: [Framework-Team] review bundle for PLIP 195 ready
Previously Raphael Ritz wrote: Tom Lazar wrote: there is, however, one issue i'd like to bring up, namely if it would be a desirable behaviour, if uninstalling ProductOne would also uninstall ProductTwo. since there is a current trend of 'exploding' products into smaller, re-usable components i could imagine that quite a few users might get frustrated when they install a product 'just to check it out' and that then populates the list of installed products with several dependencies which they then need to de-install manually. two weeks later nobody will remember what ProductTwo does or how it got installed. any ideas on this? while I think I see your point I would be against making that the default because it could easily break in situations where you have multiple cross dependencies. Like product A depends on B but product C also depends on B. Then uninstalling A will break C (you can take that further if you like). Keeping track of those kinds of dependencies to do the right thing on uninstall might be tricky. Automatic uninstalling is probably not the right approach. For Debian I once came up (and this was added to apt 10 years later) with the concept of marking packages as automatically installed when a user does not install them by hand but they are pulled in as dependencies of another package. The packaging system can then do an analysis to see if there are installed packages that are marked as being automatically installed but which no other installed package depends on. If so you can tell the user that they can be safely removed. In the command-line interface that looks like this: snow:/home/wichert# apt-get install gnotime Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: squid-common Use 'apt-get autoremove' to remove them. On the other hand it could be convenient to offer it as an option in the UI to list the dependencies on uninstall and to ask whether they should be removed (or which ones). But for this to be helpful the quickinstaller would still need to maintain a dependency matrix for the above mentioned reason. There are enough utility methods to figure that out: QI has some methods to determine which GS profile belongs to a package and GS can give you the list of dependencies for a profile. also, there's this paragraph in the plip that i don't understand: --snip-- One possible problem is that GenericSetup will only warn if a dependency is missing. This means that if a required product has not downloaded and installed in the instance by the user he will not get a proper error message. What's not clear? A warning isn't an error meaning GS will happily install a product even though a dependency might be missing. It will issue a warning (in the event log) but who cares about warnings ;-) It's a warning users will never see. CMFQuickInstaller should not offer to install a product if its dependencies are not installable. I'm not sure yet what the right behaviour for GS is here. Obviously the product will be broken in such a situation therefore it would be better for GS to fail and raise an error instead. But this is GS territory where we are more on the user side. So maybe we should bring this up on zope-cmf? I assume Tres or Yuppie might have an opinion here as well. The relevant code in GS isn't designed for that right now but that should be quite easy to change. In fact I'll probably need to do that to anyway since it makes sense to have the support methods for that in GS rather than in QI. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] review bundle for PLIP 195 ready
Tom Lazar wrote: [..] i've installed the buildout and done some TTW testing in the ZMI and in the plone control panel: everything worked as expected. in fact, the only difference in behaviour was that installing ProductOne did indeed also install ProductTwo, there were none of the previously reported effects observable such as locked/un-uninstallable products etc. ... because Wichert changed it more or less right after I had brought this up ... there is, however, one issue i'd like to bring up, namely if it would be a desirable behaviour, if uninstalling ProductOne would also uninstall ProductTwo. since there is a current trend of 'exploding' products into smaller, re-usable components i could imagine that quite a few users might get frustrated when they install a product 'just to check it out' and that then populates the list of installed products with several dependencies which they then need to de-install manually. two weeks later nobody will remember what ProductTwo does or how it got installed. any ideas on this? while I think I see your point I would be against making that the default because it could easily break in situations where you have multiple cross dependencies. Like product A depends on B but product C also depends on B. Then uninstalling A will break C (you can take that further if you like). Keeping track of those kinds of dependencies to do the right thing on uninstall might be tricky. Or to give another example: Just imagine you have installed quills ;-) indirectly via quills.remoteblogging. Now you realize you don't don't want or need the remote blogging part but you do want to use the core blogging features. How would you go about uninstalling remote blogging without uninstalling quills? On the other hand it could be convenient to offer it as an option in the UI to list the dependencies on uninstall and to ask whether they should be removed (or which ones). But for this to be helpful the quickinstaller would still need to maintain a dependency matrix for the above mentioned reason. also, there's this paragraph in the plip that i don't understand: --snip-- One possible problem is that GenericSetup will only warn if a dependency is missing. This means that if a required product has not downloaded and installed in the instance by the user he will not get a proper error message. What's not clear? A warning isn't an error meaning GS will happily install a product even though a dependency might be missing. It will issue a warning (in the event log) but who cares about warnings ;-) Obviously the product will be broken in such a situation therefore it would be better for GS to fail and raise an error instead. But this is GS territory where we are more on the user side. So maybe we should bring this up on zope-cmf? I assume Tres or Yuppie might have an opinion here as well. This problem does not exist for products shipped as eggs: eggs allow the developer to specify dependencies which will be enforced by tools such as buildout and setuptools/easy_install. --snap-- other than that +1 from me, definitly! +1 from me as well. Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] review bundle for PLIP 195 ready
On 03.12.2007, at 23:12, Wichert Akkerman wrote: Previously Wichert Akkerman wrote: I have prepared a review bundle for PLIP 195: https://svn.plone.org/svn/plone/review/plip195-dependencies There were a couple of bugs related to handling of export steps in GenericSetup. Those have been fixed now and I have updated the bundle to include them. i've installed the buildout and done some TTW testing in the ZMI and in the plone control panel: everything worked as expected. in fact, the only difference in behaviour was that installing ProductOne did indeed also install ProductTwo, there were none of the previously reported effects observable such as locked/un-uninstallable products etc. there is, however, one issue i'd like to bring up, namely if it would be a desirable behaviour, if uninstalling ProductOne would also uninstall ProductTwo. since there is a current trend of 'exploding' products into smaller, re-usable components i could imagine that quite a few users might get frustrated when they install a product 'just to check it out' and that then populates the list of installed products with several dependencies which they then need to de-install manually. two weeks later nobody will remember what ProductTwo does or how it got installed. any ideas on this? also, there's this paragraph in the plip that i don't understand: --snip-- One possible problem is that GenericSetup will only warn if a dependency is missing. This means that if a required product has not downloaded and installed in the instance by the user he will not get a proper error message. This problem does not exist for products shipped as eggs: eggs allow the developer to specify dependencies which will be enforced by tools such as buildout and setuptools/easy_install. --snap-- other than that +1 from me, definitly! cheers, tom Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] review bundle for PLIP 195 ready
Wichert Akkerman wrote: I have prepared a review bundle for PLIP 195: https://svn.plone.org/svn/plone/review/plip195-dependencies this is a standard buildout, so you can get everything up and running using the standard mantra: svn co https://svn.plone.org/svn/plone/review/plip195-dependencies cd plip195-dependencies python2.4 bootstrap.py bin/buildout bin/instance fg aside from the updated GenericSetup and CMFQuickInstallerTool I added two very trivial products that demonstrate the dependency support. If you install ProductOne you should see ProductTwo appear automatically. Maybe there's something wrong on my side but when calling buildout I just got: [EMAIL PROTECTED]:~/buildouts/reviewing/plip195-dependencies$ bin/buildout Getting distribution for 'plone.recipe.plone'. Got plone.recipe.plone 3.0.3. Getting distribution for 'zc.recipe.egg'. Got zc.recipe.egg 1.0.0. Installing plone. While: Installing plone. An internal error occured due to a bug in either zc.buildout or in a recipe being used: ValueError: too many values to unpack :-( Raphael While testing this I ran into a problem we currently see with portal_setup: the setup tool is currently registered as a utility. This means that it you access it through getToolByName and import a profile none of the import steps will be able to use self.REQUEST. I added a work-around for that (see the XXX comment) in this review bundle, but we need to fix that in Plone 3.0 as well. Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] review bundle for PLIP 195 ready
On Nov 28, 2007, at 1:54 PM, Raphael Ritz wrote: Wichert Akkerman wrote: I have prepared a review bundle for PLIP 195: https://svn.plone.org/svn/plone/review/plip195-dependencies Maybe there's something wrong on my side but when calling buildout I just got: [...] the buildout works nicely here — that's including adding a plone site and quick-installing the sample product, which then triggers installing its dependencies as well... andi -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.0.3 released! -- http://plone.org/products/plone PGP.sig Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] review bundle for PLIP 195 ready
Raphael Ritz wrote: Thanks Andi for reassuring me that the problem is indeed on my side (I still didn't fully recover from a crash of my machine recently - maybe even caused by the unified installer but I digress ...) and sorry to Wichert for me potentially indicating there could be something wrong with his buildout. Again it was my fault. No problem, glad to see it is working for you now. Now to the real thing. Everything seems to be working as indicated. So far, I only noticed the following: Installing ProductOne indeed triggers installation of ProductTwo but after that ProductTwo disappears from the plone add-on products panel completely. In ZMI it is listed as an installed product but without the option to tick it for un- or reinstall. Not sure this is intended. Maybe I intended that when I initially wrote that, however I've realized since that locking the dependencee is not the right approach: it makes it impossible to upgrade or uninstall the dependencee. I've modified that in the code and updated the buildout. Wichert. -- Wichert Akkerman [EMAIL PROTECTED] It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team