Hanno Schlichting wrote at 2009-2-8 14:14 +0100:
Wichert Akkerman wrote:
I'ld rather not see a whole slew of extra packagse appear. I also wonder
how the extra number of packages and increasing size of sys.path
influence performance and restrictions on environments like GAE.
For environments
Hanno Schlichting wrote:
Wichert Akkerman wrote:
I'ld rather not see a whole slew of extra packagse appear. I also wonder
how the extra number of packages and increasing size of sys.path
influence performance and restrictions on environments like GAE.
For environments like GAE you don't
Jim Fulton wrote at 2009-2-8 13:00 -0500:
...
IMO, introducing an extra is like introducing a new package and in a
rather complicated way.
I agree with the first part of your sentence -- but cannot follow you
with the second part:
How can 'extra' : sequence of required distributions
be
On Feb 10, 2009, at 1:49 PM, Dieter Maurer wrote:
Jim Fulton wrote at 2009-2-8 13:00 -0500:
...
IMO, introducing an extra is like introducing a new package and in a
rather complicated way.
I agree with the first part of your sentence -- but cannot follow you
with the second part:
How
Hey,
So the general idea would be to remove the complication extras
introduce in reasoning about packages. Extras can be removed in two
ways:
* carefully restructure dependency relationships between packages so
that extras are no longer needed (typically for test extras this can
be done)
*
Jim Fulton wrote at 2009-2-10 14:01 -0500:
On Feb 10, 2009, at 1:49 PM, Dieter Maurer wrote:
Jim Fulton wrote at 2009-2-8 13:00 -0500:
...
IMO, introducing an extra is like introducing a new package and in a
rather complicated way.
I agree with the first part of your sentence -- but cannot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hanno Schlichting wrote:
[snip]
Anything you'd actually be +1 on? :)
I haven't figured out yet, what I'd like to do with ZCML and
zope.configuration in general. It seems to me that ZCML is right now too
tightly bound to
Hey,
Tres Seaver wrote:
[snip]
repoze.bfg takes yet another approach.
I'm sure there are new ZCML directives it introduces, but it also forked
the current ZCML directives that are in zope.component for basic
component registration, to reduce its dependencies. Perhaps that fork
can be
Hello,
Monday, February 9, 2009, 5:58:34 PM, you wrote:
The fork is not merely to reduce dependencies: BFG also wants to
eliminate the requirement that there be one global component registry
to rule them all, which is pretty deeply embedded in zope.component.
Breaking that assumption allows
Previously Martijn Faassen wrote:
We have several ways to go:
a) continue with the current extra dependencies situation like in
zope.component, and in fact clean up other packages that define ZCML to
declare ZCML extra dependencies.
+1
I'ld rather not see a whole slew of extra packagse
2009/2/8 Dieter Maurer die...@handshake.de:
Each individual extra :extra is equivalent to a separate
package _extra depending on (and potentially many
other things). The extras are just a convenient way to avoid
cluttering the distribution namespace.
That said, I like a).
+1
Wichert Akkerman wrote:
I'ld rather not see a whole slew of extra packagse appear. I also wonder
how the extra number of packages and increasing size of sys.path
influence performance and restrictions on environments like GAE.
For environments like GAE you don't want setuptools and its magic
Martijn Faassen wrote:
Hanno Schlichting wrote:
Martijn Faassen wrote:
[snip]
a) continue with the current extra dependencies situation like in
zope.component, and in fact clean up other packages that define ZCML to
declare ZCML extra dependencies.
-1 from me.
[snip motivation I agree
On Feb 7, 2009, at 11:07 AM, Martijn Faassen wrote:
Hi there,
We've recently had some discussions on where to place the
implementation
of various ZCML directives. This post is to try to summarize the issue
and analyze the options we have.
Right now ZCML directives are implemented in
Martin Aspeli wrote:
[snip]
I see no problem with starting with zope.component, but I'd consider
both naming conventions and package structure conventions in a wider
context before making the leap with zope.component, to reduce the chance
of inconsistencies in the future.
We already had a
Martijn Faassen wrote:
Hanno Schlichting wrote:
[snip]
Anything you'd actually be +1 on? :)
I haven't figured out yet, what I'd like to do with ZCML and
zope.configuration in general. It seems to me that ZCML is right now too
tightly bound to application configuration. Zope2 and Five need
Hi there,
We've recently had some discussions on where to place the implementation
of various ZCML directives. This post is to try to summarize the issue
and analyze the options we have.
Right now ZCML directives are implemented in packages that contain other
implementation. For example,
Martijn Faassen wrote:
We've recently had some discussions on where to place the implementation
of various ZCML directives. This post is to try to summarize the issue
and analyze the options we have.
Thanks for summarizing this!
We have several ways to go:
a) continue with the current
Hey Hanno,
Thanks for your feedback!
Hanno Schlichting wrote:
Martijn Faassen wrote:
[snip]
a) continue with the current extra dependencies situation like in
zope.component, and in fact clean up other packages that define ZCML to
declare ZCML extra dependencies.
-1 from me.
[snip
Hi Martijn,
Without comparison otherwise, you may find my thoughts here useful:
http://www.martinaspeli.net/articles/granting-plone-an-api
a) continue with the current extra dependencies situation like in
zope.component, and in fact clean up other packages that define ZCML to
declare ZCML
20 matches
Mail list logo
