AW: [Zope3-dev] product installer? because of bootstrap hock
Roger ineichen
dev at projekt01.ch
Mon Mar 1 05:31:42 EST 2004
Mit freundlichen Grüssen
Roger Ineichen
_____________________________
END OF MESSAGE
> -----Ursprüngliche Nachricht-----
> Von: zope3-dev-bounces+dev=projekt01.ch at zope.org
> [mailto:zope3-dev-bounces+dev=projekt01.ch at zope.org] Im
> Auftrag von Jim Fulton
> Gesendet: Sonntag, 29. Februar 2004 17:50
> An: dev at projekt01.ch
> Cc: zope3-dev at zope.org
> Betreff: Re: [Zope3-dev] product installer? because of bootstrap hock
>
>
> Roger ineichen wrote:
> > Dear zope3 dev members,
> >
> > If somebody is developing a product with a own service and
> > content objects in this service.
>
> I discourage product authors from providing new services.
> Most cases where this has is done are better served by utilities.
>
> We are activell replacing most such services with utilities.
>
> > They have to install the
> > service first and add content objects via TTW to this service.
>
> Or use file-system based blugins. But, again. utilities are better.
>
> > Or add the service via own bootstrap class.
>
> Basically, you need to create a subscriber to DatabaseOpened events.
>
> Because the current event system is to complex, you seem to
> have to write a class. Most subscribers are more naturally
> written as functions. The zope.app.event.function.Subscriber
> class makes this easier.
>
> > For Zope stuff, this is done in app.process.bootstrap.py
>
> This should be more distributed than it is. There's too much
> stuff in this file, and inheritence makes it more complex
> than it should be.
>
> Even if you think it makes sense to provide a new service, I
> question whether it should be automagically installed by a
> bootstrapping process. We do this for a few services, but not
> all. We happen to be getting rid of some of the services
> we've done this for.
>
> > Now somebody is developing a product there whould be nice to have a
> > product installer service.
> >
> > The product installer service should do:
> > 1. register services to the installer with .zcml
> > 2. bootstrap the registred services
> > 3. register content objects to the service (if needed)
> > or do somthing with the content objects and service.
> > 4. Deinstall the product in TTW (this should deinstall
> > the services and make shure next time we start zope
> > we don't have broken services in zodb.)
> >
> > 5. Perhaps we can also install the product via TTW
> >
> > I'm realy not sure if there is such a mechanism
> > allready in Zope3. Perhaps I missed somthing?
> >
> > Is anybody starting somthing like this?
> >
> > Or should I first develope a product like this
> > in Zope3 Products. That we can see it's usable?
>
> I don't think this is necessary. Almost all of what you
> describe can be done with ZCML.
>
> Leaving aside the fact that you need to edit products.zcml to
> install a product (I'll come back to this below), your
> product zcml file:
>
> - Registeres new service types, which I discourage, and, if necessary
> provides a global service installation.
>
> - Provides a IDatabaseOpenedEvent subscriber that does any required
> bootstrapping. Again, I think we should think long and hard about
> whether such bootstrapping is really needed.
>
> The unstall use case in the presense of bootstrapping is an
> interesting one that deserves more consideration. I suppose
> that if a file-system-based product provides bootstrapping of
> some sort, it should provide a facility to undo that. I'd
> rather not get into this now, though, because:
>
> - There is a lot of other work to do, and
Yes, I know, thanks for your answer.
> - I don't think that most products should do this sort of thing.
>
> On the topic of editing products.zcml, Fred Drake is working
> on a prototype for package management for Zope. The initial
> goal of the effort is to support better in-place builds of
> the CVS tree and Zope source and binary distributions that
> are not bound by the CVS tree. The eventual goal is to have
> a flexible package-management system for file-system-based
> code that is part of a larger Python packaging system.
>
> As a part of this effort, we have decided to expant the zcml
> include directive to allow file-globs in include-directive
> package and file attributes. This will allow us to have
> product directories that simple package installers can place
> files into and remove files from, eliminating the need to
> edit products.zcml.
That sounds great.
> Jim
>
> --
> Jim Fulton mailto:jim at zope.com Python Powered!
> CTO (540) 361-1714 http://www.python.org
> Zope Corporation http://www.zope.com http://www.zope.org
>
>
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev at zope.org http://mail.zope.org/mailman/listinfo/zope3-dev
>
More information about the Zope3-dev
mailing list