Re: [Zope3-dev] Pluggins vs Application Definition
Stephan Richter wrote: This is interesting. I agree with Philipp though that a simple install tool would be better than one magic location. Indeed, but don't eggs already provide tools for this? I think the ZCML slugs are very cool I think they suck, sorry... it's one of the first things I hit with Zope 3 over Christmas :-( and if we have a tool (as make does now) Please god, not make... that does this one step, then we effectively have drop-in packages. No, drop in packages means you either use a package-manner like interface, like aptitude, a binary installer, or actually dropping a single file into a directory. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Pluggins vs Application Definition
Stephan Richter wrote: On Saturday 11 February 2006 16:50, Jim Fulton wrote: - Application developers need to build an application. They will generally want fairly tight control over what goes into the application. For them, it's valuable to say in an explicit way what they want. - If the application is extensible, then application users will want to be able to extend the application by adding pluggins. If application users are not technically sophisticated, or, more importantly, not technically interested, they peobably would prefer to just drop something into a special directory and be done with it. In summary, I think we need *both* approaches, as they serve different needs. This is interesting. I agree with Philipp though that a simple install tool would be better than one magic location. I think the ZCML slugs are very cool and if we have a tool (as make does now) that does this one step, then we effectively have drop-in packages. BTW, I think that a tool is also better, because it would allow us to keep track of the installed packages and do dependency checking, package-db maintenance, etc. Just randomly thinking... I also think an install script is a good way of facading the actual process. In fact for my pythonproducts product (allows one to use python packages as zope2 products without the Products directory) I was considering providing a py script to do this for zope2 products. Zope 2 developers see zcml slugs and say, what, things have gotten harder going to zope3?. - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Pluggins vs Application Definition
Rocky Burt wrote: Zope 2 developers see zcml slugs and say, what, things have gotten harder going to zope3?. This isn't a contradiction of what Rocky Burt said, but I feel the need to assert that harder doesn't necessarily mean worse. It's also not necessarily better either. Now back to your regularly scheduled, non-truistic messages. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Pluggins vs Application Definition
On Saturday 11 February 2006 16:50, Jim Fulton wrote: - Application developers need to build an application. They will generally want fairly tight control over what goes into the application. For them, it's valuable to say in an explicit way what they want. - If the application is extensible, then application users will want to be able to extend the application by adding pluggins. If application users are not technically sophisticated, or, more importantly, not technically interested, they peobably would prefer to just drop something into a special directory and be done with it. In summary, I think we need *both* approaches, as they serve different needs. This is interesting. I agree with Philipp though that a simple install tool would be better than one magic location. I think the ZCML slugs are very cool and if we have a tool (as make does now) that does this one step, then we effectively have drop-in packages. BTW, I think that a tool is also better, because it would allow us to keep track of the installed packages and do dependency checking, package-db maintenance, etc. Just randomly thinking... Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Pluggins vs Application Definition
Rob Jeschofnik wrote: Jim Fulton wrote: In summary, I think we need *both* approaches, as they serve different needs. I'd have to agree... so +1 .. but I'd suggest that the application/plugin should have a way of defining which ways it can (or prefers, if it can't be enforced) to be included, so it is clear that Package-X is really a plugin for Product-Y, rather than a whole new stand-alone product. Maybe. I'm not sure it will always be clear that a package can only be used a particular way. But your point is well taken and deserves more though. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Pluggins vs Application Definition
Some recent discussions on the distutils-sig mailing list have helped me to understand some issues related to the ways we extend the Zope application server. Traditionally, in Zope 2, you extended Zope by dropping product packages into a special Products package. This was very convenient in many ways, but doesn't always provide enough control or visibiity to what's going on. In Zope 3, we went with a more explicit installation mechanism, in which people had to explicitly cause a package's ZCML files to be loaded for it to be used. We added a mechanism to make this easier, by simply dropping a file into a special directory, package-includes, so an installer wouldn't have to fool with pointy brackets. I've noticed that at Zope Corporation, for our customer projects, we tend not to use package-includes. We prefer to explicitly include packages we use directly oin our application ZCML files. (As applications, may be composed of several layers, we may include things at multiple levels.) In thinking about this, I realized that there are two different users here with different concerns: - Application developers need to build an application. They will generally want fairly tight control over what goes into the application. For them, it's valuable to say in an explicit way what they want. - If the application is extensible, then application users will want to be able to extend the application by adding pluggins. If application users are not technically sophisticated, or, more importantly, not technically interested, they peobably would prefer to just drop something into a special directory and be done with it. In summary, I think we need *both* approaches, as they serve different needs. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Pluggins vs Application Definition
Jim Fulton wrote: In summary, I think we need *both* approaches, as they serve different needs. I'd have to agree... so +1 .. but I'd suggest that the application/plugin should have a way of defining which ways it can (or prefers, if it can't be enforced) to be included, so it is clear that Package-X is really a plugin for Product-Y, rather than a whole new stand-alone product. rob ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
