[Framework-Team] review bundle for PLIP 195 ready

[Raphael Ritz]

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