Fred Drake wrote:
On 10/17/07, Martin Aspeli <[EMAIL PROTECTED]> wrote:
The main win, IMHO, is to avoid the requirement for people to install
slugs for third party products. Slugs suck - they are confusing to
explain and people forget them all the time. Buildout makes it a bit
easier, but it's still not a terribly good solution.
Slugs are evil; agreed. We never use them. They were an accident of
the "instance" tree inherited from older versions of Zope, and how
that tree was re-interpreted for Zope 3. They never worked well, and
did no one any favors.
Glad we all agree.
For example, say you want to install oi.plum. You need to add the line
'oi.plum' twice - once under 'eggs' and once under 'zcml' in your
buildout.cfg. Forget the latter, and the package doesn't work properly
(or at all).
I actually really like this; I don't get the configuration for a
package unless I ask for it. It's not unusual to want only the code
and not the default configuration for a package.
Right - but you're building an application, and you're pretty
experienced with Zope. A lot of Plone users just want to install a
plug-in (a product), basically. Before, they just dropped it into a
directory. Now, they declare it twice in a file (presuming there's a
cheese shop release). That's a (small) step backwards (duplication).
Declaring it once would be a step forwards (no manual download)
If we had entry points, we could just load the egg. Internally, oi.plum
may use <include /> as much as necessary to load *its* dependencies, but
that's not something the user of the package needs to worry about.
Requiring a package doesn't say anything about how it's going to be
used; making an assumption about that is really bad.
Maybe. I agree there should be an option not to do this, and many eggs
may choose *not* to use an entry point. For things like Plone add-on
products, though, it makes much more sense to have it be automatic. To
generalise further - if what you're installing is a high level, cohesive
product, with a UI and an install method and all the rest of it, having
installation be as simple as possible is a big win. For the components
further down the stack (e.g. the things that these high level products
are depending on!), having the processing be explicit (via <include />
directives) makes more sense.
If Zope loaded entry-point ZCML automatically (maybe with an on/off
switch in zope.conf for those who need more fine grained control) that'd
be a pretty nice solution.
I suspect I'd always want it off. Picking up configuration
willy-nilly is too dangerous.
Maybe it's off by default, then, but I *know* this would make the add-on
products story in Plone easier: I've seen people struggle with slugs,
editing site.zcml is far tto scary, and you don't always have a package
that you own to include other things from.
I suspect entry points would make life simpler for other systems that
used a similar mechanism for plug-ins/add-ons. However, I agree that
they're not appropriate for more fundamental libraries.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -