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