Re: [Zope-dev] ZCML implementations: where should they go

2009-02-10 Thread Dieter Maurer
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 like GAE you don't want setuptools and its magic to be
part of your application. This is were repackaging your entire app into
one zipped egg or some other flat structure comes in handy.

But you can do that (packaging everything into a single zip)
at home -- and can interpret extras there (without a need
to have setuptools to call in your deployment environment.

Setuptools and eggs are a distribution format from my point of view.
They are certainly not the best way to deploy your applications. The
growing sys.path is affecting performance to some degree in all
deployment environments.

I think your single zip would not mind whether it were build
from a flat egg structure or from one with :extra



-- 
Dieter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZCML implementations: where should they go

2009-02-10 Thread Shane Hathaway
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 want setuptools and its magic to be
 part of your application. This is were repackaging your entire app into
 one zipped egg or some other flat structure comes in handy.
 
 Setuptools and eggs are a distribution format from my point of view.
 They are certainly not the best way to deploy your applications. The
 growing sys.path is affecting performance to some degree in all
 deployment environments.

Well, zc.buildout ought to be able to eliminate this concern for GAE 
deployment.  I haven't tried the recipe below, but it certainly seems 
like the right idea.

http://pypi.python.org/pypi/rod.recipe.appengine

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZCML implementations: where should they go

2009-02-10 Thread Dieter Maurer
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 more complicated than creating, maintaining and
  distributing a complete package?



-- 
Dieter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZCML implementations: where should they go

2009-02-10 Thread Jim Fulton

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 can 'extra' : sequence of required distributions
  be more complicated than creating, maintaining and
  distributing a complete package?


Because you have to remember to test each valid permutation of the  
package.  I bet no one does.  Also, users have to be aware of the  
extras. PyPI doesn't advertise extras nor are there standard ways to  
document them. In general, it makes an already complicated packaging  
system more complicated.

Jim

--
Jim Fulton
Zope Corporation


___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZCML implementations: where should they go

2009-02-10 Thread Martijn Faassen
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)

* extract the code that is causing the extra and move it, either into
an existing package or into a new one. zope.component is a prime
candidate for this treatement.

At most, zope.component should provide implementations of configuration
actions that do not involve extra dependencies like zope.security. The
actual implementation of the directives can then reuse these core
actions and add the extra registrations they need.

I think there's good evidence that zope.component shouldn't be
providing the implementations directly:

* repoze.zcml - reimplements the directives sans security and with
concern for multiple registries

* grokcore.component - reimplements the functionality of these actions
but not reusing the action code, simply using provideAdapter and
provideUtility as underlying actions.

So, zope.component is both doing too much and not pulling its weight
in helping with configuration, as we have two packages that entirely
go around its configuration implementations right now.

I think we should study repoze.zcml and see whether we cannot fold
part of that implementation into zope.component as actions that can be
reused by both repoze.zcml as well as grokcore.component. We can then
move the implementations of the standard security-conscious actions
from zope.component, perhaps into zope.security (as that's really what
the extra dependency is all about, and the extra bit that gets added
to the standard directives is security-support), or perhaps into a
newly created package.

I suspect that if we create a new ZCML only packages we'd get very far
with something that would replace the ZCML defined in zope.component
and zope.security both, and with another package that tackles various
browser oriented directives. We're not looking at vastly expanding the
amount of packages.

Regards,

Martijn
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZCML implementations: where should they go

2009-02-10 Thread Dieter Maurer
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 follow you
 with the second part:

  How can 'extra' : sequence of required distributions
  be more complicated than creating, maintaining and
  distributing a complete package?


Because you have to remember to test each valid permutation of the  
package.  I bet no one does.

But that is the same when each extra is represented by an individual
package. Then, too, you have to test each valid combination -- and
few will do it.

 Also, users have to be aware of the  
extras. PyPI doesn't advertise extras

I am interested in extras only when I am interested in the package
itself. Of course, the package should document in some way
relevant extras.

nor are there standard ways to  
document them.

I recently looked at documentation for a few standard packages
on PyPI -- and apart from all using rest and a bit of
classifiction, I could not detect much standard for them, too.


In general, it makes an already complicated packaging  
system more complicated.

That's something I do not get...

An extra is a shorthand for a separate package with a few extra dependancies.

Sure, shorthands are not strictly necessary.
Sure, complexity increases slightly.
Nevertheless, they are often valuable.



-- 
Dieter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZCML implementations: where should they go

2009-02-09 Thread Tres Seaver
-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 application configuration. Zope2 and Five need
 different action handlers and this will continue to be the case for the
 next years and possibly forever.
 
 I thought significant process was made on the ability to reuse more 
 handlers now that Zope 2 has got __parent__ support. Not enough?
 
 Grok has different needs for the
 configuration part of your application. 
 
 Grok does reuse some actions defined for the use of ZCML actually, 
 though sometimes we do introduce new ones.
 
 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 undone if we improve the way we break things down (to anticipate 
 what you're saying below).

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 multiple BFG apps to run in the same
process, with incompatible components registered, without any chance
that they will step on each other's toes.

 Once we define a Grok-like API for Plone we will probably end
 up with yet some other kind of different semantics.
 
 If you define altogether new actions that are Plone specific there might 
 not be too big of a problem in overlap there.
 
 My gut feeling is that the best long term answer would be to figure out
 how to split zope.configuration and ZCML kind of in the middle. What
 parts of application configuration are actually reusable and which are
 not.

Reusable configuration is a bit of an oxymoron:  if everybody *must*
use the configuration, then it isn't configuration at all, but software.

I think, however, that this discussion is about where to put the meta
bits (the parts which actually implement ZCML directives), rather than
rehashing the library vs. application problem (where to put the
configuration).

 How does application configuration and system configuration like
 paste.ini and zope.conf fir together?

 Just trying to push out ZCML in itself seems better than having it stay
 in, but not what I'd consider to be a good long term answer.
 
 I'd consider it at least a necessary step towards a long term answer, so 
 you should be +1 for step one. :)
 
 Another step would be to start taking a look at refactoring the actions 
 to increase reuse. I think refactoring the actions can be driven by the 
 needs of the code that uses it. If Zope 2 developers say: hey, we could 
 *almost* use this action if it only didn't do this, we could use that to 
 split the action into two parts so that the main part can be reused. The 
 Grok developers and Repoze developers should look for similar 
 opportunities.
 
 It might be that some actions very similar to the ones the repoze fork 
 now uses will make it back into zope.component, but that the extended 
 ones that Zope 3 requires should be extracted.
 
 Note that I don't mind much that zope.configuration has intrinsic 
 support for ZCML (besides the general action-based configuration 
 system). Grok needs that support anyway, and so will any system that at 
 least wants to support packages that load their configuration using ZCML.

I would argue that putting any ZCML-related implementation in a separate
package from the zope.component core would be a win, at least from the
perspective of clarity and dependencies.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJkE3v+gerLs4ltQ4RAvbxAJ40EfLHA+l/8ixXFmuVQJO9e15QYQCcDazx
rGxL8+ZQpfxnAPbGLV1O0GM=
=mutG
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZCML implementations: where should they go

2009-02-09 Thread Martijn Faassen
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 undone if we improve the way we break things down (to anticipate 
 what you're saying below).
 
 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 multiple BFG apps to run in the same
 process, with incompatible components registered, without any chance
 that they will step on each other's toes.

Cool, I hadn't realized that. I think it would be useful to fold that 
support into the Zope framework itself too.

[snip]
 Reusable configuration is a bit of an oxymoron:  if everybody *must*
 use the configuration, then it isn't configuration at all, but software.

  I think, however, that this discussion is about where to put the meta
  bits (the parts which actually implement ZCML directives), rather than
  rehashing the library vs. application problem (where to put the
  configuration).

Yes.

My interpretation of what Hanno said was that he was talking about 
reusing the implementation of configuration. I.e. repoze.zcml might 
define an action that zope.componentconf might use in the implementation
of its own actions. Anyway, no matter what Hanno said, I think that is 
an interesting area to explore. Grok and Five both want to reuse as much 
of the underlying action implementation in the Zope framework as possible.

[snip]
 I would argue that putting any ZCML-related implementation in a separate
 package from the zope.component core would be a win, at least from the
 perspective of clarity and dependencies.

Agreed.

It might be that the core implementations of actions a-la repoze.zcml 
could be moved into zope.component. repoze.zcml could then become a 
smaller package that simply registers the directives themselves for 
these actions.

We could then have something that builds on this (and zope.security) to 
implement the directives that zope.component now implements.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZCML implementations: where should they go

2009-02-09 Thread Adam GROSZER
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 multiple BFG apps to run in the same
 process, with incompatible components registered, without any chance
 that they will step on each other's toes.

There is something similar, z3c.baseregistry, or not?

-- 
Best regards,
 Adam GROSZERmailto:agros...@gmail.com
--
Quote of the day:
True love is when your heart and your mind are saying the same thing. 
- Leanna L. Bartram 

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZCML implementations: where should they go

2009-02-08 Thread Wichert Akkerman
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 appear. I also wonder
how the extra number of packages and increasing size of sys.path
influence performance and restrictions on environments like GAE.

 b) pull out all ZCML implementations from where they are now and put 
 them in special ZCML implementation packages. We could for instance have 
 zcml.component, or zope.component_zcml, or zope.configuration.component. 
 We had a bit of a side-tracked discussion about naming and namespace 
 packages here.

+0.5

It solves the problem in a consistent way

 c) pull out only those ZCML implementations that cause extra 
 dependencies beyond zope.configuration. So, we extract the bits of 
 zope.component into a new package, but we don't extract bits from 
 zope.security.

+0.1

This introduces inconsistencies that might be confusing.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZCML implementations: where should they go

2009-02-08 Thread Dan Korostelev
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

-- 
WBR, Dan Korostelev
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZCML implementations: where should they go

2009-02-08 Thread Hanno Schlichting
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 to be
part of your application. This is were repackaging your entire app into
one zipped egg or some other flat structure comes in handy.

Setuptools and eggs are a distribution format from my point of view.
They are certainly not the best way to deploy your applications. The
growing sys.path is affecting performance to some degree in all
deployment environments.

Hanno

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZCML implementations: where should they go

2009-02-08 Thread Hanno Schlichting
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 with]
 
 options b and c:
 +0 Seems reasonable to me.
 
 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
different action handlers and this will continue to be the case for the
next years and possibly forever. Grok has different needs for the
configuration part of your application. repoze.bfg takes yet another
approach. Once we define a Grok-like API for Plone we will probably end
up with yet some other kind of different semantics.

My gut feeling is that the best long term answer would be to figure out
how to split zope.configuration and ZCML kind of in the middle. What
parts of application configuration are actually reusable and which are
not. How does application configuration and system configuration like
paste.ini and zope.conf fir together?

Just trying to push out ZCML in itself seems better than having it stay
in, but not what I'd consider to be a good long term answer.

Hanno

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZCML implementations: where should they go

2009-02-08 Thread Jim Fulton

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 packages that contain  
 other
 implementation. For example, zope.component implements various ZCML
 directives, and zope.security implements some more.

 In the case of zope.component, a special [zcml] extras dependency
 section is  declared. If the ZCML dependencies are asked for, using
 zope.component will suddenly pull in a much larger list of  
 dependencies
 than the original zope.component dependency list. The ZCML directives
 are component-related, but do offer extra options that need bits from
 the wider Zope 3 framework, such as the security infrastructure.

 In the case of zope.security, this isn't the case. As far as I can  
 see,
 it doesn't declare any dependency beyond zope.configuration to allow  
 it
 to implement its ZCML directives.

 The dependency situation for the ZCML implementations in  
 zope.component
 doesn't appear ideal. It was therefore proposed to move the ZCML
 implementations to another package. This could be a new package, or it
 could be created.

 Following up on that, it was considered we should move *all*  
 directives
 from the packages that implement them now into special packages. This
 would allow some packages to lose the dependency on  
 zope.configuration,
 which is a relatively minor gain.

 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.

I did this in zope.component out of desperation.  (I was preparing to  
teach a PyCon tutorial on using zope.component outside of Zope.) I'm  
not at all happy with it, however, I'd be in favor of continuing it  
for existing packages with zcml implementations so as not to introduce  
backward incompatibilities.  I'd rather not do it for new packages.   
IMO, introducing an extra is like introducing a new package and in a  
rather complicated way.

 b) pull out all ZCML implementations from where they are now and put
 them in special ZCML implementation packages. We could for instance  
 have
 zcml.component, or zope.component_zcml, or  
 zope.configuration.component.
 We had a bit of a side-tracked discussion about naming and namespace
 packages here.

I think this is the right way to go for new software.


 c) pull out only those ZCML implementations that cause extra
 dependencies beyond zope.configuration. So, we extract the bits of
 zope.component into a new package, but we don't extract bits from
 zope.security.

Too complicated imo. :)

 I personally don't like extras. I think the ideal situation would be  
 if
 packages had *no* extras at all (even test extras), as it complicates
 reasoning about the dependency structure.

+1

...

 For that reason, a) is not really an option for me.

As I said above, I'm for a) because I think it is less disruptive,  
even though I share your distaste for extras.

Jim

--
Jim Fulton
Zope Corporation


___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZCML implementations: where should they go

2009-02-08 Thread Martijn Faassen
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
 different action handlers and this will continue to be the case for the
 next years and possibly forever.

I thought significant process was made on the ability to reuse more 
handlers now that Zope 2 has got __parent__ support. Not enough?

 Grok has different needs for the
 configuration part of your application. 

Grok does reuse some actions defined for the use of ZCML actually, 
though sometimes we do introduce new ones.

 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 undone if we improve the way we break things down (to anticipate 
what you're saying below).

 Once we define a Grok-like API for Plone we will probably end
 up with yet some other kind of different semantics.

If you define altogether new actions that are Plone specific there might 
not be too big of a problem in overlap there.

 My gut feeling is that the best long term answer would be to figure out
 how to split zope.configuration and ZCML kind of in the middle. What
 parts of application configuration are actually reusable and which are
 not. How does application configuration and system configuration like
 paste.ini and zope.conf fir together?
 
 Just trying to push out ZCML in itself seems better than having it stay
 in, but not what I'd consider to be a good long term answer.

I'd consider it at least a necessary step towards a long term answer, so 
you should be +1 for step one. :)

Another step would be to start taking a look at refactoring the actions 
to increase reuse. I think refactoring the actions can be driven by the 
needs of the code that uses it. If Zope 2 developers say: hey, we could 
*almost* use this action if it only didn't do this, we could use that to 
split the action into two parts so that the main part can be reused. The 
Grok developers and Repoze developers should look for similar 
opportunities.

It might be that some actions very similar to the ones the repoze fork 
now uses will make it back into zope.component, but that the extended 
ones that Zope 3 requires should be extracted.

Note that I don't mind much that zope.configuration has intrinsic 
support for ZCML (besides the general action-based configuration 
system). Grok needs that support anyway, and so will any system that at 
least wants to support packages that load their configuration using ZCML.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZCML implementations: where should they go

2009-02-08 Thread Martijn Faassen
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 rather fruitless naming discussion, which is why I'm 
still in favor of option c) (avoiding the creation of new packages where 
possible). Option b) risks us creating a lot more small packages that 
we'll have to manage, and ultimately I'd like to *reduce* the amount of 
packages in the Zope framework. And as I already said, I like small steps.

I think we should adhere to the principle that a package should have the 
code and dependencies to run its tests, with typically no test extras 
needed therefore, and no dependencies just to support testing.

I think we should also have the principle that code to configure a 
concepts introduced by a package (such as component configuration, 
security configuration) should be in that package, if at least this 
doesn't expand dependency requirements.

I saw that this principle seemed to work fairly well when we moved ZCML 
directives out of both zope.app.security and zope.app.component into 
zope.security: these directives were mostly (though not entirely) about 
security anyway, and the move didn't introduce new dependencies.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZCML implementations: where should they go

2009-02-08 Thread Hanno Schlichting
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
 different action handlers and this will continue to be the case for the
 next years and possibly forever.
 
 I thought significant process was made on the ability to reuse more 
 handlers now that Zope 2 has got __parent__ support. Not enough?

Some progress has been made. But some of the actions actually do have a
different semantic in Five, like all the resource things. The URL scheme
they produce is different for example. Some others will need to adhere
to different security needs or use different base classes for the
automagically inserted classes. Last time I looked there was no clear
next step that would need to be taken to remove more custom handlers.

 Just trying to push out ZCML in itself seems better than having it stay
 in, but not what I'd consider to be a good long term answer.
 
 I'd consider it at least a necessary step towards a long term answer, so 
 you should be +1 for step one. :)

I'm +0, since I don't yet know, where the journey will take us and if
this is a step into the right direction. If others drive this forward,
I'm fine with it. I'm just not going to put lots of my time into it just
yet.

Hanno

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZCML implementations: where should they go

2009-02-07 Thread Hanno Schlichting
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 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. I see the test extra as a necessary evil to get us moving
with the lessened-dependency project. Multiple extras will just cause an
increasing number of combinations of packages which aren't tested
anymore. If you have a extra in your package, it should be possible to
move the added functionality from the extra into a package that depends
on the original package.

 b) pull out all ZCML implementations from where they are now and put 
 them in special ZCML implementation packages. We could for instance have 
 zcml.component, or zope.component_zcml, or zope.configuration.component. 
 We had a bit of a side-tracked discussion about naming and namespace 
 packages here.
 
 c) pull out only those ZCML implementations that cause extra 
 dependencies beyond zope.configuration. So, we extract the bits of 
 zope.component into a new package, but we don't extract bits from 
 zope.security.

+0 Seems reasonable to me.

Hanno

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZCML implementations: where should they go

2009-02-07 Thread Martijn Faassen
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 motivation I agree with]

options b and c:
 +0 Seems reasonable to me.

Anything you'd actually be +1 on? :)

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZCML implementations: where should they go

2009-02-07 Thread Martin Aspeli
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 extra dependencies.

-0.5

I think this will require more discipline than usual, and it'll a pain 
to test how a package behaves both with and without extras.

 b) pull out all ZCML implementations from where they are now and put 
 them in special ZCML implementation packages. We could for instance have 
 zcml.component, or zope.component_zcml, or zope.configuration.component. 
 We had a bit of a side-tracked discussion about naming and namespace 
 packages here.

+0.5

I would suggest we have a namespace package and a naming convention to 
allow this to grow over time. For example, we could have a zope.zcml.* 
naming convention, so you'd have zope.zcml.component, zope.zcml.content 
and so on. Having a single package could become painful when people 
start refactoring and branching, as you could easily get into situations 
where it becomes hard to upgrade or manage releases.

 c) pull out only those ZCML implementations that cause extra 
 dependencies beyond zope.configuration. So, we extract the bits of 
 zope.component into a new package, but we don't extract bits from 
 zope.security.

-0.5

This policy sounds confusing to me, which means that people will 
probably screw it up. :)

 For that reason, a) is not really an option for me. That leaves b) and 
 c). I think for now we should go with c), as it's the smallest step 
 forward that will help clean up things. That is, we either find and 
 appropriate package that makes sense for the ZCML implementations in 
 zope.component, or we create a new package. Of course if we create a new 
 package we still have a naming discussion ahead and I risk sparking 
 another naming discussion (as it's easy to have an opinion about names).
 
 So, what do people think about option c)?

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.

Martin

-- 
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
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )