On 9/13/06, Martin Aspeli <[EMAIL PROTECTED]> wrote:
Hi,
> > As I said, I'm still wary of using GS as the main install mechanism,
> > even if the quickinstaller can now find them thanks to Hanno. The
> > uninstall question is still unresolved as far as I can see, in cases
> > where you need custom cleanup code, and the
> > re-run-all-import-steps-every-time idea scares me - it depends on
> > every extension profile being well-behaved with respect to
> > re-installation, which it very well may not be.
>
> Because Hanno's solution uses the QI, it has the same uninstall
> features as the QI, regardless of whether the install was procedural
> or done using GS.
I don't think Hanno's solution has an uninstall script (yet). As I
understood it, it can deal with the case where QI auto-uninstalls
things like FTIs and workflows, but not where you need to write an
uninstall() method of your own.
Perhaps not, but it's not as if this is a difficult thing to add. In
fact I would be a little surprised if adding an Extensions/Install.py
with only an uninstall method didn't work already.
> The repeatability of install steps is important,
> but it was true for procedural installs with the QI too,
Was it? There is some ambiguity as to whether a re-install meant
re-initialise or don't re-initialise. Anyone who assumes it means
re-initialise when they write a custom GS import handler (the
out-of-the-box ones are fairly well-written, thankfully) will need to
ensure that their handlers are re-runnable without side-effect.
Basically, GS makes the re-install button a bit meaningless. If you
re-install a traditionally installed product, it calls
uninstall(reinstall=True); install(reinstall=True). If you re-install
a GS based product, it'll have to re-run all the import steps for
every GS-installed product. If I click re-install on Poi, it'll
re-install listen as well. That means that neither Poi nor listen can
really do any kind of re-initialisation upon re-install.
Hm, yes the QI makes it possible to really differentiate the reinstall
from install, bt practically no products that I have seen make
explicit use of this functionality (just as very few actually bother
to make custom uninstall methods). During reinstall the default QI
uninstall essentially does nothing besides mark the product as
uninstalled, and the QI install method does the exact same thing it
did on plain install, unless it explicitly checks the reinstall
parameter (which is rare from what I've seen). The big difference is
that in procedural installs it was common to check if something exists
before adding it, and skipping it if it does (this will likely be true
of the procedural handlers in GS installs since the same peope will be
writing them), but XML based installs do not do such checks, and that
is where problems might come in.
>I don't see
> the issue really. If one has non-repeatable install steps in their GS
> profile they will figure it out very quickly dring development in my
> experience.
You have a lot more faith in third party developers than I do :)
It's not about faith, it's just very difficult to make a product
without having to reinstall it a couple of times. If something breaks
on reinstall because certain handlers are not repeatable it will kind
of halt development, no?
The other issue, of course, is whether it's acceptable to tell people
to re-write all their install scripts. Again, we're talking about
breaking almost every third party product out there today if we
*require* GS (of course, supporting it where it's already in use is
great).
Because the solution is based on QI, people can continue using QI
based installs as long as they like (or until we deprecate it, which I
think there are no plans for currently). I think the benefits of GS
based installs are pretty self evident, and people who like that kind
of thing will start using them. Is anybody really talking about
requiring only GS based installs for this release? The most we could
do is deprecate non-GS installs for removal in 4.0, and it's not clear
to me that we're even ready to take that step.
Alec
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
