Re: [Repoze-dev] bfg zcml directives...

[Paul Everitt]

On Dec 20, 2008, at 1:59 PM, Chris McDonough wrote:

> As a result of messing around with the ZCA + ZCML outside the  
> context of Zope,
> I've found that it may be possible to significantly reduce the  
> number of egg
> dependencies of BFG by replacing the code that allows the following  
> ZCML
> directives to work:
>
> - utility
> - adapter
> - interface
> - subscriber
>
> As such, I'm thinking of ditching the handlers written "zope"  
> namespace for
> these directives in favor of handler written in the "bfg"  
> namespace.  So, for

Interesting idea.  I suppose the decorator syntax wouldn't change, but  
the machinery behind it would.

> example, rather than doing:
>
>  http://namespaces.zope.org/zope";>
>
>   provides=".interfaces.IFoo"
> factory=".foo.Foo"/>
>
>  
>
> You would instead do:
>
>  http://namespaces.repoze.org/bfg";>
>
>   provides=".interfaces.IFoo"
> factory=".foo.Foo"/>
>
>  
>
> The down side of this is that it would mean that existing  
> applications that used
> ZCML would need to change their ZCML, or they'd at least need to  
> declare
> "zope.security" as an install_requires dependency and do a manual  
> include of the
> "zope.component" ZCML:
>
>  

I think it's pretty reasonable to make that requirement in order to  
get that gain.  Meaning, apps would still work with a one-line  
setup.py change and a line of ZCML.

> Creating parallel "adapter", "utility" and "subscriber" handlers is  
> really how I
> should have started things out, but I didn't, and given that there  
> are people
> using the system in the wild that this would cause problems for in a  
> new
> release, I wanted to ask for comments.
>
> Here are the dependencies we might be able to shed by doing this:
>
> zope.location-3.4.0-py2.4.egg
> zope.publisher-3.5.4-py2.4.egg
> zope.security-3.5.2-py2.4-macosx-10.5-i386.egg
> zope.traversing-3.5.0a4-py2.4.egg
> zope.i18n-3.6.0-py2.4.egg
> pytz-2008i-py2.4.egg
>
> My personal opinion is that doing this is "worth it" for the long  
> term.  None of
> these packages actually *do* anything for bfg apps, they're just  
> required to
> satisfy dependencies of features we can't use.

For applications that do a Zope-ish architecture (ZODB, security,  
etc.), how many of those packages would they need to pull in manually?

--Paul
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Chris McDonough]

Paul Everitt wrote:
> 
> On Dec 20, 2008, at 1:59 PM, Chris McDonough wrote:
> 
>> As a result of messing around with the ZCA + ZCML outside the context
>> of Zope,
>> I've found that it may be possible to significantly reduce the number
>> of egg
>> dependencies of BFG by replacing the code that allows the following ZCML
>> directives to work:
>>
>> - utility
>> - adapter
>> - interface
>> - subscriber
>>
>> As such, I'm thinking of ditching the handlers written "zope"
>> namespace for
>> these directives in favor of handler written in the "bfg" namespace. 
>> So, for
> 
> Interesting idea.  I suppose the decorator syntax wouldn't change, but
> the machinery behind it would.

zope.configuration doesn't provide any decorator syntax, but if you mean the
ZCML syntax, yes, exactly; it wouldn't change for the "utility" or "adapter"
directives.  One "fallout" change would be that instead of:

  

The view directive would be just:

  

(because the "bfg" XML namespace would be the default).

> 
>> example, rather than doing:
>>
>>  http://namespaces.zope.org/zope";>
>>
>>  > provides=".interfaces.IFoo"
>> factory=".foo.Foo"/>
>>
>>  
>>
>> You would instead do:
>>
>>  http://namespaces.repoze.org/bfg";>
>>
>>  > provides=".interfaces.IFoo"
>> factory=".foo.Foo"/>
>>
>>  
>>
>> The down side of this is that it would mean that existing applications
>> that used
>> ZCML would need to change their ZCML, or they'd at least need to declare
>> "zope.security" as an install_requires dependency and do a manual
>> include of the
>> "zope.component" ZCML:
>>
>>  
> 
> I think it's pretty reasonable to make that requirement in order to get
> that gain.  Meaning, apps would still work with a one-line setup.py
> change and a line of ZCML.

Right.

> 
>> Creating parallel "adapter", "utility" and "subscriber" handlers is
>> really how I
>> should have started things out, but I didn't, and given that there are
>> people
>> using the system in the wild that this would cause problems for in a new
>> release, I wanted to ask for comments.
>>
>> Here are the dependencies we might be able to shed by doing this:
>>
>> zope.location-3.4.0-py2.4.egg
>> zope.publisher-3.5.4-py2.4.egg
>> zope.security-3.5.2-py2.4-macosx-10.5-i386.egg
>> zope.traversing-3.5.0a4-py2.4.egg
>> zope.i18n-3.6.0-py2.4.egg
>> pytz-2008i-py2.4.egg
>>
>> My personal opinion is that doing this is "worth it" for the long
>> term.  None of
>> these packages actually *do* anything for bfg apps, they're just
>> required to
>> satisfy dependencies of features we can't use.
> 
> For applications that do a Zope-ish architecture (ZODB, security, etc.),
> how many of those packages would they need to pull in manually?

Security is not a feature provided by any Zope package in a BFG app; ZODB
requires whatever its setup.py says it requires.

In terms of the Zope-ish applications we (Agendaless) are developing under BFG,
no changes would need to be made to any setup.py "install_requires".

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Paul Everitt]

On Dec 20, 2008, at 2:12 PM, Chris McDonough wrote:

> Paul Everitt wrote:
>>
>> On Dec 20, 2008, at 1:59 PM, Chris McDonough wrote:
>>
>>> As a result of messing around with the ZCA + ZCML outside the  
>>> context
>>> of Zope,
>>> I've found that it may be possible to significantly reduce the  
>>> number
>>> of egg
>>> dependencies of BFG by replacing the code that allows the  
>>> following ZCML
>>> directives to work:
>>>
>>> - utility
>>> - adapter
>>> - interface
>>> - subscriber
>>>
>>> As such, I'm thinking of ditching the handlers written "zope"
>>> namespace for
>>> these directives in favor of handler written in the "bfg" namespace.
>>> So, for
>>
>> Interesting idea.  I suppose the decorator syntax wouldn't change,  
>> but
>> the machinery behind it would.
>
> zope.configuration doesn't provide any decorator syntax, but if you  
> mean the

Sorry, I meant repoze.bfg.convention.  I believe that, under the hood,  
it's doing the same configuration work as ZCML.

>
> ZCML syntax, yes, exactly; it wouldn't change for the "utility" or  
> "adapter"
> directives.  One "fallout" change would be that instead of:
>
>   for=".models.MyModel"
> view=".views.my_view"
> />
>
> The view directive would be just:
>
>   for=".models.MyModel"
> view=".views.my_view"
> />
>
> (because the "bfg" XML namespace would be the default).
>
>>
>>> example, rather than doing:
>>>
>>> http://namespaces.zope.org/zope";>
>>>
>>> >>provides=".interfaces.IFoo"
>>>factory=".foo.Foo"/>
>>>
>>> 
>>>
>>> You would instead do:
>>>
>>> http://namespaces.repoze.org/bfg";>
>>>
>>> >>provides=".interfaces.IFoo"
>>>factory=".foo.Foo"/>
>>>
>>> 
>>>
>>> The down side of this is that it would mean that existing  
>>> applications
>>> that used
>>> ZCML would need to change their ZCML, or they'd at least need to  
>>> declare
>>> "zope.security" as an install_requires dependency and do a manual
>>> include of the
>>> "zope.component" ZCML:
>>>
>>> 
>>
>> I think it's pretty reasonable to make that requirement in order to  
>> get
>> that gain.  Meaning, apps would still work with a one-line setup.py
>> change and a line of ZCML.
>
> Right.
>
>>
>>> Creating parallel "adapter", "utility" and "subscriber" handlers is
>>> really how I
>>> should have started things out, but I didn't, and given that there  
>>> are
>>> people
>>> using the system in the wild that this would cause problems for in  
>>> a new
>>> release, I wanted to ask for comments.
>>>
>>> Here are the dependencies we might be able to shed by doing this:
>>>
>>> zope.location-3.4.0-py2.4.egg
>>> zope.publisher-3.5.4-py2.4.egg
>>> zope.security-3.5.2-py2.4-macosx-10.5-i386.egg
>>> zope.traversing-3.5.0a4-py2.4.egg
>>> zope.i18n-3.6.0-py2.4.egg
>>> pytz-2008i-py2.4.egg
>>>
>>> My personal opinion is that doing this is "worth it" for the long
>>> term.  None of
>>> these packages actually *do* anything for bfg apps, they're just
>>> required to
>>> satisfy dependencies of features we can't use.
>>
>> For applications that do a Zope-ish architecture (ZODB, security,  
>> etc.),
>> how many of those packages would they need to pull in manually?
>
> Security is not a feature provided by any Zope package in a BFG app;  
> ZODB
> requires whatever its setup.py says it requires.
>
> In terms of the Zope-ish applications we (Agendaless) are developing  
> under BFG,
> no changes would need to be made to any setup.py "install_requires".

Right, I meant the latter.  For people that are writing BFG  
applications that smell like Zope (e.g. KARL), how many of those  
packages would still be used, thus lessening the "win" in that case?

--Paul
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Chris McDonough]

Paul Everitt wrote:
>> zope.configuration doesn't provide any decorator syntax, but if you
>> mean the
> 
> Sorry, I meant repoze.bfg.convention.  I believe that, under the hood,
> it's doing the same configuration work as ZCML.

It is but it's a separate issue.  We could choose to make parallel
utility/subscriber/adapter/interface decorators if we wanted (ala grokcore), but
 it'd be a feature unrelated to this change.

>>> For applications that do a Zope-ish architecture (ZODB, security, etc.),
>>> how many of those packages would they need to pull in manually?
>>
>> Security is not a feature provided by any Zope package in a BFG app; ZODB
>> requires whatever its setup.py says it requires.
>>
>> In terms of the Zope-ish applications we (Agendaless) are developing
>> under BFG,
>> no changes would need to be made to any setup.py "install_requires".
> 
> Right, I meant the latter.  For people that are writing BFG applications
> that smell like Zope (e.g. KARL), how many of those packages would still
> be used, thus lessening the "win" in that case?

None of those are used by our apps.

- C
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Martin Aspeli]

Chris McDonough wrote:

> Creating parallel "adapter", "utility" and "subscriber" handlers is really 
> how I
> should have started things out, but I didn't, and given that there are people
> using the system in the wild that this would cause problems for in a new
> release, I wanted to ask for comments.

This seems like a fairly silly way to make repoze.bfg more of an island 
than it already is. What is the real-world cost of those dependencies? I 
know there are a few problems - running on GAE, detailed security 
audits, that kind of thing - but I'm not convinced it's an issue for 
most people.

Why can't we instead try to work with the Zope 3 project to untangle the 
dependencies there? It's definitely a desirable goal in that project 
too, but one that hasn't happened for lack of the type of analysis 
you've done here.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Chris McDonough]

Martin Aspeli wrote:
> Chris McDonough wrote:
> 
>> Creating parallel "adapter", "utility" and "subscriber" handlers is really 
>> how I
>> should have started things out, but I didn't, and given that there are people
>> using the system in the wild that this would cause problems for in a new
>> release, I wanted to ask for comments.
> 
> This seems like a fairly silly way to make repoze.bfg more of an island 
> than it already is. What is the real-world cost of those dependencies? I 
> know there are a few problems - running on GAE, detailed security 
> audits, that kind of thing - but I'm not convinced it's an issue for 
> most people.
> Why can't we instead try to work with the Zope 3 project to untangle the 
> dependencies there? It's definitely a desirable goal in that project 
> too, but one that hasn't happened for lack of the type of analysis 
> you've done here.

Note that the reasons aren't only to get rid of dependencies for the sake of
getting rid of them.  And note that the dependency graph is not as fucked as it
might appear, given the requirements of the existing directives.  There are more
practical reasons to create a different set of core directive handlers, and
there are reasons the dependency graph is the way it is now, which I should have
mentioned:

- Zope wants the concept of "trusted" adapters and utilities.  From
  the docstring of the "trusted" attribute of IAdapterDirective:
  "Trusted adapters have unfettered access to the objects they adapt.
  If asked to adapt security-proxied objects, then, rather than
  getting an unproxied adapter of security-proxied objects, you
  get a security-proxied adapter of unproxied objects".

  If this doscstring description alone isn't enough to make you want
  to rip that particular code out, please consider that BFG has no
  concept of "untrusted" code.  If folks use the "trusted" flag on
  an adapter declaration in ZCML within BFG, I have absolutely no clue
  what will happen. Its usage would be a bug in a BFG app.

  Note that this feature requires "zope.security".

- Zope wants to gate access to adapters, utilities and subscriptions
  based on a permission.  The concept of permission it uses has no
  bearing on bfg applications; utility usage is never
  security-protected in bfg apps.  Like "trusted", the usage of
  the "permission" attribute on an adapter or utility declaration
  in BFG would be a bug.

  Note that this feature requires "zope.security".

- The "interface" directive mutates the global CA registry directly.
  BFG apps don't use the global registry; they keep a CA registry
  per-app.  The usage of the global registry in a BFG app would be
  a bug.

In summary, the directives that Zope uses to make adapter, utility, interface
and subscriber registrations are far down the road of 1) encouraging the use of
"untrusted" code, 2) gating access to utility and adapter lookups based on a
concept of permission that only Zope itself has and 3) depending on the global
registry.  All of these things are either not useful for bfg or actively 
harmful.

Maybe there's some potential to create a set of core ZCML registration handlers
for utility, adapter, subscriber, and interace that are not actually part of
BFG, but on which BFG and other non-Zope apps could depend.  I suspect this is
the only realistic way to go forward: I don't think it's reasonable to tell the
people who have Zope apps in production which use these declarations that they
won't be able to use untrusted code or permission declarations, or the global
registry.

- C


___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Chris McDonough]

> Maybe there's some potential to create a set of core ZCML registration 
> handlers
> for utility, adapter, subscriber, and interace that are not actually part of
> BFG, but on which BFG and other non-Zope apps could depend.  I suspect this is
> the only realistic way to go forward: I don't think it's reasonable to tell 
> the
> people who have Zope apps in production which use these declarations that they
> won't be able to use untrusted code or permission declarations, or the global
> registry.

In that spirit, here is the first cut at some documentation for a package I'm
now working on.  Comments appreciated...

Documentation for repoze.zcml
=

:mod:`repoze.zcml` is a package which provides core ZCML directives
for the Zope Component Architecture (particularly, ``utility``,
``subscriber``, and ``adapter``).

Note that ``zope.configuration`` already *has* implementations of
handlers that allow similar directives to work.  You should only use
the ``repoze.zcml`` versions of these directives if your application
doesn't need the more advanced features of the "stock" directive types
of the same names present in ``zope.configuration``.  The "stock"
implementations use the concepts of "permissions", and "trusted"
adapters and utilities.  In most applications, these features are
unnecessary, and exposing them to users may be harmful.  Using
``repoze.zcml`` in this case makes it possible to use ZCML with fewer
Zope Python packages as dependencies, and removes the possibility that
your users will attempt to use these advanced features without any
understanding of what they do.

.. note:: The effect of ``repoze.zcml`` directives is exactly
   equivalent to the effect that the "stock" directives would have,
   save for the omission of more advanced features.

:mod:`repoze.zcml` contains "meta" ZCML that can be included within
your application's ZCML that makes certain directives work (listed
below).  After this meta ZCML is loaded, you can use the directives.

For an overall description of the concepts backing the directives
defined within :mod:`repoze.zcml`, see `A Comprehensive Guide to Zope
Component Architecture `_.

Usage
-

To make use of :mod:`repoze.zcml`, you should install the
:mod:`repoze.zcml` package, then subsequently include its "meta.zcml"
from within some ZCML that is used by your application::

  

Thereafter, you will be able to use the directive types it defines
within your ZCML.

The directives defined in :mod:`repoze.zcml` are defined within the
namespace ``http://namespaces.repoze.org/zcml``.  Therefore to use any
of the :mod:`repoze.zcml`-defined directives without a
namespace-qualified name, you should write your ZCML like so:

.. code-block:: xml

  http://namespaces.repoze.org/zcml";>



  

On the other hand, if you want to use these directives with a
qualified name within another application that already has a default
``xmlns``, you can do so by adding a different XML namespace to the
``configure`` tag::

  http://namespaces.zope.org/zope";>
   xmlns:zcml="http://namespaces.repoze.org/zcml";>



   

Directives
--

*adapter*
  The ``adapter`` directive registers an adapter within the component
  architecture registry.

Example:

.. code-block:: xml

   

.. directive:: .. factory

   The factory which creates an adapter (dotted name).

.. directive:: .. provides

   This implies the interface that the adapter provides (dotted name).

.. directive:: .. for

   This implies the interface(s) which the adapter is "for".  (One or
   more dotted names).

.. directive:: .. name

   The name by which the adapter should be looked up.

*utility*
  The ``utility`` directive registers a utility within the component
  architecture registry.

Example:

.. code-block:: xml

   

.. directive:: .. component

   Describes the component registered as the adapter.  This attribute
   is mutually exlusive with the ``factory`` attribute.

.. directive:: .. provides

   Describes the provides interface for an adapter.

.. directive:: .. for

   Describes the for interface(s) for an adapter.

.. directive:: .. name

   Describes the name of the adapter.

*subscriber*
  The ``subscriber`` directive registers an event subscriber within
  the component architecture registry.

Example:

.. code-block:: xml

   

.. directive:: .. handler

   The handler for the subscriber.  This is a subscriber which does
   not require a factory.  This attribute is mutually exclusive with
   the ``factory`` directive.

.. directive:: .. factory

   The factory which creates an subscriber (dotted name).  This
   attribute is mutually exclusive with the ``handler`` directive.

.. directive:: .. provides

   This implies the interface that the subscriber adapter provides
   (dotted name).

.. directive:: .. for

   This implies the interface(s) which the subscriber adapter is
   "for".  (One or more dotted names).

Indices and tables
--

Re: [Repoze-dev] bfg zcml directives...

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris McDonough wrote:
> As a result of messing around with the ZCA + ZCML outside the context of Zope,
> I've found that it may be possible to significantly reduce the number of egg
> dependencies of BFG by replacing the code that allows the following ZCML
> directives to work:
> 
> - utility
> - adapter
> - interface
> - subscriber
> 
> As such, I'm thinking of ditching the handlers written "zope" namespace for
> these directives in favor of handler written in the "bfg" namespace.  So, for
> example, rather than doing:
> 
>   http://namespaces.zope.org/zope";>
> 
> provides=".interfaces.IFoo"
>  factory=".foo.Foo"/>
> 
>   
> 
> You would instead do:
> 
>   http://namespaces.repoze.org/bfg";>
> 
> provides=".interfaces.IFoo"
>  factory=".foo.Foo"/>
> 
>   
> 
> The down side of this is that it would mean that existing applications that 
> used
> ZCML would need to change their ZCML, or they'd at least need to declare
> "zope.security" as an install_requires dependency and do a manual include of 
> the
> "zope.component" ZCML:
> 
>   
> 
> Creating parallel "adapter", "utility" and "subscriber" handlers is really 
> how I
> should have started things out, but I didn't, and given that there are people
> using the system in the wild that this would cause problems for in a new
> release, I wanted to ask for comments.
> 
> Here are the dependencies we might be able to shed by doing this:
> 
> zope.location-3.4.0-py2.4.egg
> zope.publisher-3.5.4-py2.4.egg
> zope.security-3.5.2-py2.4-macosx-10.5-i386.egg
> zope.traversing-3.5.0a4-py2.4.egg
> zope.i18n-3.6.0-py2.4.egg
> pytz-2008i-py2.4.egg
> 
> My personal opinion is that doing this is "worth it" for the long term.  None 
> of
> these packages actually *do* anything for bfg apps, they're just required to
> satisfy dependencies of features we can't use.

+1.  We aren't going to get the "fly what you test" crowd to strip the
stupidity any time soon:  "if they can't get the joke, then fork them."


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

iD8DBQFJTX1f+gerLs4ltQ4RAoHFAKDKi+hBHBetdgFUPaI3E9jy+5fDQACgrg2o
z/PPhRJblb2UgVfBbnosIIU=
=Dr1a
-END PGP SIGNATURE-
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Chris McDonough]

Chris McDonough wrote:
>> Maybe there's some potential to create a set of core ZCML registration 
>> handlers
>> for utility, adapter, subscriber, and interace that are not actually part of
>> BFG, but on which BFG and other non-Zope apps could depend.  I suspect this 
>> is
>> the only realistic way to go forward: I don't think it's reasonable to tell 
>> the
>> people who have Zope apps in production which use these declarations that 
>> they
>> won't be able to use untrusted code or permission declarations, or the global
>> registry.
> 
> In that spirit, here is the first cut at some documentation for a package I'm
> now working on.  Comments appreciated...

That package is now done...

http://static.repoze.org/zcmldocs

and

http://pypi.python.org/pypi/repoze.zcml/0.1

I've adjusted the trunk of bfg and the trunk of chameleon.zpt to use ZCML
declaration implementations from this rather than using the "stock"
implementations from zope.component.  We will thus wind up shedding these
dependencies in the next release of BFG:

zope.security
zope.location
zope.publisher
zope.traversing

We can't shed the i18n-related packages as chameleon still legitimately depends
on them.

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Martin Aspeli]

Chris McDonough wrote:

> That package is now done...
> 
> http://static.repoze.org/zcmldocs
> 
> and
> 
> http://pypi.python.org/pypi/repoze.zcml/0.1
> 
> I've adjusted the trunk of bfg and the trunk of chameleon.zpt to use ZCML
> declaration implementations from this rather than using the "stock"
> implementations from zope.component.

Given that Plone also uses chameleon.zpt (via five.pt) this means that, 
if I understand correctly, Plone now gains this dependency, and part of 
the Plone stack uses what will seem to most people like an arbitrary, 
almost-identical-but-not-quite way of configuring components that's 
different to what the rest of the stack uses.

I realise Plone isn't your main concern here, but this is basically 
what's going to happen to anyone who use lower level Repoze components 
that use this means of configuration in a non-BFG context (or at least 
in conjunction with more general Zope stuff).

I think that's a shame, because it's an argument against adopting Repoze 
components in other frameworks. Plone already has far too many 
almost-identical-but-not-quite ways of configuring things and we're 
trying hard to consolidate. We don't have to use repoze.zcml ourselves 
(and we almost certainly won't), but as people try to understand the 
stack, it's another thing they have to be aware of. As we start using 
more Repoze components (trunk already pulls in siz repoze eggs) it's 
something we may start bumping up against higher up in the stack than 
the template engine.

 From experience, it's not unlikely that people will then start copying 
the approach used by Chameleon and then get rather confused when they 
realise that  can mean two subtly different things depending 
on an xmlns line at the top of their configure.zcml.

I'm not saying what you've done was bad for repoze.bfg, but at least be 
cognisant that repoze.bfg and by extension, possibly the wider repoze 
stack, is starting to smell more like a fork of "Zope" (or at least a 
particular combination of various Zope components), that's going to make 
the attractive bits of the stack harder to swallow for other users of Zope.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Wichert Akkerman]

Previously Martin Aspeli wrote:
> Chris McDonough wrote:
> 
> > That package is now done...
> > 
> > http://static.repoze.org/zcmldocs
> > 
> > and
> > 
> > http://pypi.python.org/pypi/repoze.zcml/0.1
> > 
> > I've adjusted the trunk of bfg and the trunk of chameleon.zpt to use ZCML
> > declaration implementations from this rather than using the "stock"
> > implementations from zope.component.
> 
> Given that Plone also uses chameleon.zpt (via five.pt) this means that, 
> if I understand correctly, Plone now gains this dependency, and part of 
> the Plone stack uses what will seem to most people like an arbitrary, 
> almost-identical-but-not-quite way of configuring components that's 
> different to what the rest of the stack uses.

I'm not sure that is true: people can still use the standard zope zcml
directorives instead of the repoze.zcml alternatives and everything will
work normally.

The only downside is that chameleon.zpt will pull in a few extra
packages, but you yourself have argued that that should not bother
people.

Wichert.

-- 
Wichert Akkerman It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Hanno Schlichting]

Chris McDonough wrote:
> Maybe there's some potential to create a set of core ZCML registration 
> handlers
> for utility, adapter, subscriber, and interace that are not actually part of
> BFG, but on which BFG and other non-Zope apps could depend.  I suspect this is
> the only realistic way to go forward: I don't think it's reasonable to tell 
> the
> people who have Zope apps in production which use these declarations that they
> won't be able to use untrusted code or permission declarations, or the global
> registry.

Should this discussion happen on the zope-dev list or is that too
hostile these days ;)

>From my point of view, configuration of components is an area where
every Zope-based project takes a different approach to right now:

- Zope3 has its own handlers tied in deeply into the rest of the application

- Zope2 has its own handlers (in Products.Five) which are highly
dependent on the rest of the application

- Grok uses a different approach and has written its own configuration
approach

- Plone might want to adopt a Grok-style approach and will need to use
yet another kind of five.grok or similar handlers

- repoze.bfg now gained its own implementation of the core ZCML handlers

What all projects have in common, is the abstract concept behind those
handlers and the dependency on zope.component and zope.interface. We all
have interfaces, utilities and adapters.

What is different is the exact way these concepts need to be configured
to fit into the framework. One problematic bit is that depending on the
framework the configured result actually has different semantics at some
points as well.

What can we do about this?

Every framework makes it more obvious that they have different
implementations of the same concepts and provide them in a different
namespace / approach? That results in integration packages to be
required to be able to use a package from one framework in a different one.

We all claim to be in the same namespace and let the result of the
configuration be dependent on the framework it is used in? That is more
convenient to (re-) use but has the risk of hiding the semantic differences.

Hanno

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Chris McDonough]

Hanno Schlichting wrote:
> Chris McDonough wrote:
>> Maybe there's some potential to create a set of core ZCML registration 
>> handlers
>> for utility, adapter, subscriber, and interace that are not actually part of
>> BFG, but on which BFG and other non-Zope apps could depend.  I suspect this 
>> is
>> the only realistic way to go forward: I don't think it's reasonable to tell 
>> the
>> people who have Zope apps in production which use these declarations that 
>> they
>> won't be able to use untrusted code or permission declarations, or the global
>> registry.
> 
> Should this discussion happen on the zope-dev list or is that too
> hostile these days ;)

I'd be happy if this discussion migrated to zope-dev.

> 
>>From my point of view, configuration of components is an area where
> every Zope-based project takes a different approach to right now:
> 
> - Zope3 has its own handlers tied in deeply into the rest of the application
> 
> - Zope2 has its own handlers (in Products.Five) which are highly
> dependent on the rest of the application
> 
> - Grok uses a different approach and has written its own configuration
> approach
> 
> - Plone might want to adopt a Grok-style approach and will need to use
> yet another kind of five.grok or similar handlers
> 
> - repoze.bfg now gained its own implementation of the core ZCML handlers
> 
> What all projects have in common, is the abstract concept behind those
> handlers and the dependency on zope.component and zope.interface. We all
> have interfaces, utilities and adapters.
> 
> What is different is the exact way these concepts need to be configured
> to fit into the framework. One problematic bit is that depending on the
> framework the configured result actually has different semantics at some
> points as well.
> 
> What can we do about this?
> 
> Every framework makes it more obvious that they have different
> implementations of the same concepts and provide them in a different
> namespace / approach? That results in integration packages to be
> required to be able to use a package from one framework in a different one.
> 
> We all claim to be in the same namespace and let the result of the
> configuration be dependent on the framework it is used in? That is more
> convenient to (re-) use but has the risk of hiding the semantic differences.

It just doesn't seem feasible to break backwards compatibility to make the
"core" directives do less all the time.

It'd work to add knobs to the core directive packages that let it detect whether
the directives use more advanced features like "trusted" and "permission",  but
it might make the ZCA code a little convoluted.  I suspect that floating that
idea on zope-dev would be the only way to tell.  I wonder if anyone has enough
context using the ZCA outside of Zope for the idea itself to make much sense to
them.

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Chris McDonough]

Wichert Akkerman wrote:
> Previously Martin Aspeli wrote:
>> Chris McDonough wrote:
>>
>>> That package is now done...
>>>
>>> http://static.repoze.org/zcmldocs
>>>
>>> and
>>>
>>> http://pypi.python.org/pypi/repoze.zcml/0.1
>>>
>>> I've adjusted the trunk of bfg and the trunk of chameleon.zpt to use ZCML
>>> declaration implementations from this rather than using the "stock"
>>> implementations from zope.component.
>> Given that Plone also uses chameleon.zpt (via five.pt) this means that, 
>> if I understand correctly, Plone now gains this dependency, and part of 
>> the Plone stack uses what will seem to most people like an arbitrary, 
>> almost-identical-but-not-quite way of configuring components that's 
>> different to what the rest of the stack uses.
> 
> I'm not sure that is true: people can still use the standard zope zcml
> directorives instead of the repoze.zcml alternatives and everything will
> work normally.
> 
> The only downside is that chameleon.zpt will pull in a few extra
> packages, but you yourself have argued that that should not bother
> people.

+1

- C
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Chris McDonough]

repoze.bfg has a core concept of "pay only for what you eat", so, as Paul put it
(with a 30 point word no less!), "fidelity" with Zope is not a goal; where we
don't need things that Zope offers, we explicitly get rid of them.  This helps
keep things honest and understandable, particularly in places where concepts
overlap ("why do I need zope.security when BFG has its own security?  why do i
need zope.traversing when BFG does its own traversal?  why do i need
zope.publisher when BFG has its own publisher?").

You understand this goal, as below you argue for it in the context of Plone.  I
am sorry it needs to be one way or the other currently (either bfg gains four
dependencies and directive attributes that are actively harmful or Plone gains
one dependency), but that's how it is until we can figure out a way to get
everybody what they want.  But one thing won't happen: bfg is not going to live
with four inappropriate dependencies forever to service a goal of fidelity.  So
we can either figure out a single way that everyone wins, or we leave it as is.
 That's the set of options you lobbied for me to choose from in your original
email, so I present them back to you, where that decision is yours to make
instead of mine.

That said, to the extent that we can push functionality down into Zope bits and
help detangle dependencies in the course of doing the cleanup, we'll definitely
do so.  But if cleanup is vetoed, we are going to fix it one way or another.

- C


Martin Aspeli wrote:
> Chris McDonough wrote:
> 
>> That package is now done...
>>
>> http://static.repoze.org/zcmldocs
>>
>> and
>>
>> http://pypi.python.org/pypi/repoze.zcml/0.1
>>
>> I've adjusted the trunk of bfg and the trunk of chameleon.zpt to use ZCML
>> declaration implementations from this rather than using the "stock"
>> implementations from zope.component.
> 
> Given that Plone also uses chameleon.zpt (via five.pt) this means that, 
> if I understand correctly, Plone now gains this dependency, and part of 
> the Plone stack uses what will seem to most people like an arbitrary, 
> almost-identical-but-not-quite way of configuring components that's 
> different to what the rest of the stack uses.
> 
> I realise Plone isn't your main concern here, but this is basically 
> what's going to happen to anyone who use lower level Repoze components 
> that use this means of configuration in a non-BFG context (or at least 
> in conjunction with more general Zope stuff).
> 
> I think that's a shame, because it's an argument against adopting Repoze 
> components in other frameworks. Plone already has far too many 
> almost-identical-but-not-quite ways of configuring things and we're 
> trying hard to consolidate. We don't have to use repoze.zcml ourselves 
> (and we almost certainly won't), but as people try to understand the 
> stack, it's another thing they have to be aware of. As we start using 
> more Repoze components (trunk already pulls in siz repoze eggs) it's 
> something we may start bumping up against higher up in the stack than 
> the template engine.
> 
>  From experience, it's not unlikely that people will then start copying 
> the approach used by Chameleon and then get rather confused when they 
> realise that  can mean two subtly different things depending 
> on an xmlns line at the top of their configure.zcml.
> 
> I'm not saying what you've done was bad for repoze.bfg, but at least be 
> cognisant that repoze.bfg and by extension, possibly the wider repoze 
> stack, is starting to smell more like a fork of "Zope" (or at least a 
> particular combination of various Zope components), that's going to make 
> the attractive bits of the stack harder to swallow for other users of Zope.
> 
> Martin
> 

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Paul Everitt]

Summary: there isn't really a problem, because BFG is not Repoze.   
People that want the side-effects in BFG can still get them.   
Everybody wins.

On Dec 21, 2008, at 6:06 AM, Martin Aspeli wrote:

> I realise Plone isn't your main concern here, but this is basically
> what's going to happen to anyone who use lower level Repoze components
> that use this means of configuration in a non-BFG context (or at least
> in conjunction with more general Zope stuff).

I don't see why this is true.  Chris changed BFG, not Repoze.

Chameleon changed, and if Plone does or doesn't use Chameleon,  
Chameleon-in-Plone simply needs to internally do something tiny.  It  
already internally imposed lxml as a requirement.  This change is  
*tiny* compared libxml2+lxml+Cython.

I'm not sure it is true that use of any "lower level Repoze  
components" has changed.  Since this seems to be the heart of your  
point, can you illustrate where this is true?

BFG is not Repoze.  BFG certainly isn't trying to be Zope, and thus,  
shouldn't sign up for the mound of policies that Chris did the  
analysis on.  You didn't comment on his writeup, though: do you concur  
with his point, that the package list is laden with (harmful for non- 
Zope) policy?

Frankly, the "more of an island than it already is" lead-in comes  
across as an ill-informed insult.  BFG starts with easy_install, then  
virtualenv, then Paste, then WSGI, then WebOb, before you even see  
BFG.  It ships with Chameleon: when do you suppose Zope 2/3 will  
replace ZPT with Chameleon? BFG doesn't even *include* ZODB, much  
less, require that you have a root before you can write your non-ZODB  
application.

I think we're working harder to hang out with other Python web  
technologies than anybody else in the Zope world, by far.  You have a  
weird definition of "island".

> I think that's a shame, because it's an argument against adopting  
> Repoze
> components in other frameworks. Plone already has far too many
> almost-identical-but-not-quite ways of configuring things and we're
> trying hard to consolidate. We don't have to use repoze.zcml ourselves
> (and we almost certainly won't), but as people try to understand the
> stack, it's another thing they have to be aware of. As we start using
> more Repoze components (trunk already pulls in siz repoze eggs) it's
> something we may start bumping up against higher up in the stack than
> the template engine.
>
> From experience, it's not unlikely that people will then start copying
> the approach used by Chameleon and then get rather confused when they
> realise that  can mean two subtly different things  
> depending

Yes, because the policies in  can be harmful when used  
outside of Zope.  Chris is doing the responsible thing: not giving  
false advertising that this is the same set of  assumptions  
as Zope.

Hopefully you're not arguing that BFG should, for example, adopt the  
idea of non-trusted code, just to make sure we use the same ZCML  
directives?

> on an xmlns line at the top of their configure.zcml.
>
> I'm not saying what you've done was bad for repoze.bfg, but at least  
> be
> cognisant that repoze.bfg and by extension, possibly the wider repoze

That seems like a false leap.

--Paul

> stack, is starting to smell more like a fork of "Zope" (or at least a
> particular combination of various Zope components), that's going to  
> make
> the attractive bits of the stack harder to swallow for other users  
> of Zope.


___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Martin Aspeli]

Paul Everitt wrote:

> That seems like a false leap.

I freely admit to using hyperbole in my original email to draw out a 
debate. :-)

It does bother me a little, though, that the "fix" seems to be to 
fork/re-implement rather than to try and push something downstream. 
No-one in Zope is disagreeing that the dependencies should be untangled. 
Few people seem to have the time and impetus to do something about it. 
When BFG does, then it'd be great if that effort could benefit everyone.

My specific reaction, by the way, was not to BFG, but to Chameleon. Does 
chameleon.zpt "belong" to BFG? This wasn't my impression. And if so, 
does Plone need to be wary of adopting it, for fear of it growing a lot 
closer to a BFG philosophy that's not necessarily going to be compatible 
with Plone's architectural vision going forward?

What about the other repoze.* packages? Which ones are going to inhibit 
this parallel universe where things are done almost like other parts of 
Zope, but not quite? After ZCML, what's next?

There is an obvious risk here, as demonstrated by the chameleon.zpt 
case, that the desire to prune transitive dependencies means BFG either 
ends up being more monolithic (i.e. owning its own, tightly controlled, 
minimal versions of everything) or pushing alternate methods for things 
like configuration into lower level packages, because dependencies can't 
be kept to an absolute minimum otherwise. Re-use always carries a risk 
of getting more than you bargained for, because the author of the 
original package may not have intended it to be re-used in exactly the 
way you need.

But sorry about the "island" gripe - I'm very grateful for the work 
repoze is doing to play well in Python land, and, as you know, I'm a 
strong advocate of Plone and Zope riding that bandwagon. I just worry 
that sometimes this may mean leaving the rest of Zope behind, rather 
than work to bring it along.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Chris McDonough]

Martin Aspeli wrote:
> Paul Everitt wrote:
> 
>> That seems like a false leap.
> 
> I freely admit to using hyperbole in my original email to draw out a 
> debate. :-)
> 
> It does bother me a little, though, that the "fix" seems to be to 
> fork/re-implement rather than to try and push something downstream. 
> No-one in Zope is disagreeing that the dependencies should be untangled. 
> Few people seem to have the time and impetus to do something about it. 
> When BFG does, then it'd be great if that effort could benefit everyone.

If repoze.zcml was named zope.zcml (or zope.zcmlthatdoesless or whatever), would
that help?  The only other option would be to convince the "test what you fly,
fly what you test" crowd that we really do need permission/trusted-less ZCML
directives "in the core", and that they'll need to undergo some pain (and cease
contributing stop energy to the discussion) to allow us to get what we need.
I've never been very successful at that, so I just avoid doing it.

> My specific reaction, by the way, was not to BFG, but to Chameleon. Does 
> chameleon.zpt "belong" to BFG? This wasn't my impression. And if so, 
> does Plone need to be wary of adopting it, for fear of it growing a lot 
> closer to a BFG philosophy that's not necessarily going to be compatible 
> with Plone's architectural vision going forward?

Chameleon belongs to those who help maintain it, IMO.  Primarily this means it
belongs to Malthe, who has written 99% of its code.  I checked into it yesterday
a dependency on repoze.zcml.  I did not get permission to do so from Malthe.
But unless I have a very poor sense of judgment, I suspect Malthe will cheer
about shedding four dependencies.

As far as architectural vision, Plone makes a lot of sacrifices for backwards
compatibility, all of which are reasonable in the context it's developed in.
They make no sense, however, to other projects, and Plone can't expect other
folks to live with them forever because it has chosen to.

But if change *is* desired, there is some responsibility incumbent upon Plone
devs to get with the program here and bring some pressure to bear; you've seen
that Zope 3 development is currently landlocked, right?  Every time somebody
brings up some moderate change on zope-dev, it's more or less immediately shot
down by the folks that don't want to think about it.  What other choice do we
have but to fork?

> What about the other repoze.* packages? Which ones are going to inhibit 
> this parallel universe where things are done almost like other parts of 
> Zope, but not quite? After ZCML, what's next?

The good old slippery slope argument.  But admittedly there's some truth to it
here in the context of BFG... for BFG, what's next is whatever we goddamn well
please. ;-)  (This doesn't really extend to other repoze packages, FTR, just
BFG).  If we can help Zope in the meantime, great.

> There is an obvious risk here, as demonstrated by the chameleon.zpt 
> case, that the desire to prune transitive dependencies means BFG either 
> ends up being more monolithic (i.e. owning its own, tightly controlled, 
> minimal versions of everything) or pushing alternate methods for things
> like configuration into lower level packages, because dependencies can't 
> be kept to an absolute minimum otherwise.

Any package the Zope world would develop to solve this problem would smell
almost exactly like the one implemented in repoze.zcml.  So there's a blueprint.
 Let's figure out how to put it in the core, or not.

 Re-use always carries a risk
> of getting more than you bargained for, because the author of the 
> original package may not have intended it to be re-used in exactly the 
> way you need.
> 
> But sorry about the "island" gripe - I'm very grateful for the work 
> repoze is doing to play well in Python land, and, as you know, I'm a 
> strong advocate of Plone and Zope riding that bandwagon. I just worry 
> that sometimes this may mean leaving the rest of Zope behind, rather 
> than work to bring it along.

Taking action is the best way to move things along.  It got you interested,
didn't it? ;-)

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Paul Everitt]

On Dec 21, 2008, at 9:31 AM, Chris McDonough wrote:

> But one thing won't happen: bfg is not going to live
> with four inappropriate dependencies forever to service a goal of  
> fidelity.

Repoze is the place where we co-habitate with the goals of other  
projects, such as Zope and Plone.  BFG, though, is where we make  
something that is more fun than frustration, defining the goals and  
limits to serve the purpose of BFG.

Thus, +1M on Chris's point.  People that want the fidelity of Zope  
already have other choices.  Hell, Zope itself gives them two very  
different choices, and Grok is a third.

People who want to enjoy other Python web stuff as part of the core,  
in combination with the fun part of Zope, and strive for fun and  
minimalism, now have a place to hang out.  People that don't share  
that goal, or have the goal of Zope fidelity, are well-served elsewhere.

BFG != Zope, by the original motivation of its creation.

--Paul
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Paul Everitt]

On Dec 21, 2008, at 11:36 AM, Martin Aspeli wrote:

> Paul Everitt wrote:
>
>> That seems like a false leap.
>
> I freely admit to using hyperbole in my original email to draw out a
> debate. :-)
>
> It does bother me a little, though, that the "fix" seems to be to
> fork/re-implement rather than to try and push something downstream.
> No-one in Zope is disagreeing that the dependencies should be  
> untangled.
> Few people seem to have the time and impetus to do something about it.
> When BFG does, then it'd be great if that effort could benefit  
> everyone.

Chris provided an analysis showing that this is more than packaging.   
There are policy decisions involved.  Could you comment on his writeup  
about the policies and side effects?

Should people that want to use Zope-style components, also be forced  
to digest "trusted adapters"?  Or, is someone brave enough to convince  
the Zope world to either ditch that idea?  Or, shepherd a proposal to  
make it parameterizable?

It isn't their itch, so they won't implement the proposal.  Instead,  
you'll be asking the people that *don't* want trusted adapters, to do  
the work to paramaterize it.

Thus, this is harder than just untangling dependencies, IMO.

> My specific reaction, by the way, was not to BFG, but to Chameleon.  
> Does
> chameleon.zpt "belong" to BFG? This wasn't my impression. And if so,
> does Plone need to be wary of adopting it, for fear of it growing a  
> lot
> closer to a BFG philosophy that's not necessarily going to be  
> compatible
> with Plone's architectural vision going forward?

I presume that Chameleon belongs to Malthe et al.  I doubt a change  
would be made that he disagreed with.

But I'll invert the question: does Chameleon belong to Zope?  I  
believe Chameleon aspires to life beyond the Zope island.  If so, then  
it is a Great Thing to shed those rather harmful side effects, while  
enabling a *TRIVIAL* way to sign back up for them in Zopeland.

Everybody wins.

> What about the other repoze.* packages? Which ones are going to  
> inhibit

Yes, you made this assertion, and I'm asking you to demonstrate the  
facts behind that assertion.  Are you claiming that repoze.zope2 has  
changed?  repoze.retry?  repoze.tm?  repoze.who?

> this parallel universe where things are done almost like other parts  
> of
> Zope, but not quite? After ZCML, what's next?

Hopefully, lots of stuff is next, but for BFG.  Repoze is the place of  
co-habitation with the goals of fidelity.

> There is an obvious risk here, as demonstrated by the chameleon.zpt
> case, that the desire to prune transitive dependencies means BFG  
> either
> ends up being more monolithic (i.e. owning its own, tightly  
> controlled,

Calling bfg a monolith is, like calling it an island, just plain  
silly.  BFG is the opposite of a monolith, as I demonstrated in my  
previous mail.  Also, BFG does not have the goal of fixing Zope's  
tightly-controlled monolith.

Again, Chris spent the time to show that this is more than pruning  
transitive dependencies.  This is pruning harmful (to non-Zope), side- 
effect-ful (to non-Zope) policies that are part of the goal in Zope.

> minimal versions of everything) or pushing alternate methods for  
> things
> like configuration into lower level packages, because dependencies  
> can't
> be kept to an absolute minimum otherwise. Re-use always carries a risk
> of getting more than you bargained for, because the author of the
> original package may not have intended it to be re-used in exactly the
> way you need.
>
> But sorry about the "island" gripe - I'm very grateful for the work
> repoze is doing to play well in Python land, and, as you know, I'm a
> strong advocate of Plone and Zope riding that bandwagon. I just worry
> that sometimes this may mean leaving the rest of Zope behind, rather
> than work to bring it along.

Chris has worked hard *in Repoze*, harder than just about anybody  
else, to bridge the gap and bring it along.  He's asking that BFG be  
his own place, where he can build just the thing he wants, and leave  
out the parts he doesn't want.  People don't have to use it if that  
isn't their goal.

--Paul


>
>
> Martin
>
> -- 
> Author of `Professional Plone Development`, a book for developers who
> want to work with Plone. See http://martinaspeli.net/plone-book
>
> ___
> Repoze-dev mailing list
> Repoze-dev@lists.repoze.org
> http://lists.repoze.org/listinfo/repoze-dev

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris McDonough wrote:
> Hanno Schlichting wrote:
>> Chris McDonough wrote:
>>> Maybe there's some potential to create a set of core ZCML registration 
>>> handlers
>>> for utility, adapter, subscriber, and interace that are not actually part of
>>> BFG, but on which BFG and other non-Zope apps could depend.  I suspect this 
>>> is
>>> the only realistic way to go forward: I don't think it's reasonable to tell 
>>> the
>>> people who have Zope apps in production which use these declarations that 
>>> they
>>> won't be able to use untrusted code or permission declarations, or the 
>>> global
>>> registry.
>> Should this discussion happen on the zope-dev list or is that too
>> hostile these days ;)
> 
> I'd be happy if this discussion migrated to zope-dev.
> 
>> >From my point of view, configuration of components is an area where
>> every Zope-based project takes a different approach to right now:
>>
>> - Zope3 has its own handlers tied in deeply into the rest of the application
>>
>> - Zope2 has its own handlers (in Products.Five) which are highly
>> dependent on the rest of the application
>>
>> - Grok uses a different approach and has written its own configuration
>> approach
>>
>> - Plone might want to adopt a Grok-style approach and will need to use
>> yet another kind of five.grok or similar handlers
>>
>> - repoze.bfg now gained its own implementation of the core ZCML handlers
>>
>> What all projects have in common, is the abstract concept behind those
>> handlers and the dependency on zope.component and zope.interface. We all
>> have interfaces, utilities and adapters.
>>
>> What is different is the exact way these concepts need to be configured
>> to fit into the framework. One problematic bit is that depending on the
>> framework the configured result actually has different semantics at some
>> points as well.
>>
>> What can we do about this?
>>
>> Every framework makes it more obvious that they have different
>> implementations of the same concepts and provide them in a different
>> namespace / approach? That results in integration packages to be
>> required to be able to use a package from one framework in a different one.

No:  just *don't use the directives*.  Reusing policy-laden
configuration is an anti-goal, compared to re-using software.

>> We all claim to be in the same namespace and let the result of the
>> configuration be dependent on the framework it is used in? That is more
>> convenient to (re-) use but has the risk of hiding the semantic differences.

- -100 to that option.  This is why we have namespaces in the first place.

> It just doesn't seem feasible to break backwards compatibility to make the
> "core" directives do less all the time.
> 
> It'd work to add knobs to the core directive packages that let it detect 
> whether
> the directives use more advanced features like "trusted" and "permission",  
> but
> it might make the ZCA code a little convoluted.  I suspect that floating that
> idea on zope-dev would be the only way to tell.  I wonder if anyone has enough
> context using the ZCA outside of Zope for the idea itself to make much sense 
> to
> them.

This is why stripping dependencies is hard:  the dependencies don't hurt
the folks who want the policies served by them, while stripping them
out, and parameterizing the code which currently hardwires the policies,
makes those same developers' lives harder (now they have to add the
dependncies to their own code) and their code more convoluted.  We can't
even get them to agree to simple things like stripping out *test*
dependencies from the main 'install_requires';  what makes you think
they would be willing to move the "Zope{2,3}-only" stuff out?

Note that one change I would make to the docs is to make using the 'bfg'
namespace *not* the default in the examples;  marking each non-Zope
directive with 'bfg:' (in the examples, not necessarily in a real-world
config) would remind people, "this is not your father's Oldzopemobile,"
as is true already for 'bfg:view'.


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

iD8DBQFJTxqK+gerLs4ltQ4RAt3VAJsEcZgz/ubvN85EYSptdtEx59H+cgCeJYru
IQF/f0utHYPYb/61VKlheP4=
=pbDp
-END PGP SIGNATURE-
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Martin Aspeli]

Mmmm... I didn't mean for this to get quite so emotional. :)

Chris (and Agendaless) is of course free to do whatever he wants with 
BFG. And as I've shown many times, I'm very supportive of the great work 
coming out of the Repoze project.

However, if Repoze is aiming to bridge the gap between the mature Zope 
components and the WSGI-enabled world of other Python frameworks and 
tools, then we should at least debate when the pendulum swings further 
away from Zope.

> Everybody wins.

I'm not quite sure about this. Anyone who wants to use traditional Zope 
packages that are configured using the standard zope ZCML stuff in a BFG 
application now has to contend with two methods of configuration that 
look identical but for an xmlns line at the top of the ZCML file, but 
are implemented in different places. That sounds like a recipe for 
confusion (especially considering that there is a reasonable amount of 
documentation and doctests out there that refer to the "old" way). It 
also sounds really hard to debug if ever there's a conflict between the 
two types of handlers.

 > Repoze != BFG

This is certainly true. However, we've seen that a desire to do 
something in BFG (prune dependencies by replacing a core Zope package 
with a homespun version with tighter dependency control) had a knock-on 
effect on transitive dependencies in the Repoze world, which in turn 
impacts other users of those packages. The change in Chameleon meant 
that Repoze lost a few dependencies it didn't need, and Plone gained a 
few (or at least one) it didn't need.

This is what I meant about BFG becoming a monolith: not that it's not 
built from reusable packages, but rather that if you want to control the 
transitive dependencies like this, you're going to have to re-implement 
any part of zope.* or plone.* or other users of the traditional ZCML way 
of configuring the CA, with repoze.* equivalents that are not thus 
polluted.

If you want to pull in, say, plone.supermodel (a "pure Zope 3" package 
that should be re-usable and may be useful to BFG if it ever wants to 
serialise Zope 3 schema interfaces to/from an XML representation) well, 
it uses zope:* ZCML directives. Are you going to fork plone.supermodel? 
Are you going to re-implement your own version? Are you going to 
advocate that it too moves to repoze.zcml? None of those options sound 
particularly attractive.

I certainly feel for Chris when he says he's worried about stop energy 
in Zope 3 land. There's a fair amount of that. But things do get done, 
when there's a will. Jim is a huge advocate of untangling dependencies. 
As are the Grok people. As are the Plone people. Repoze and Grok are 
where the innovation in the Zope world is happening right now, so I 
think they have a license to push things through. Instead of 
repoze.zcml, perhaps we could have a branch of the relevant zope.* 
package? We could then merge that later.

repoze.zcml is a symptom that an improvement is needed further down the 
stack. In the Plone world, we've learned the hard way that rolling your 
own to avoid having to push something deeper into the stack is a costly 
strategy in the long run. Paul should certainly know this. :) It may be 
that Repoze should take a bit more pain now, in the form of writing a 
proposal and putting up with some flak or politicking, to save having to 
maintain a growing amount of custom code later. Or not. But at least 
let's not give up before we've tried.

Cheers,
Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Martin Aspeli]

Tres Seaver wrote:

> Note that one change I would make to the docs is to make using the 'bfg'
> namespace *not* the default in the examples;  marking each non-Zope
> directive with 'bfg:' (in the examples, not necessarily in a real-world
> config) would remind people, "this is not your father's Oldzopemobile,"
> as is true already for 'bfg:view'.

+1

Martin

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Wichert Akkerman]

Previously Martin Aspeli wrote:
> If you want to pull in, say, plone.supermodel (a "pure Zope 3" package 
> that should be re-usable and may be useful to BFG if it ever wants to 
> serialise Zope 3 schema interfaces to/from an XML representation) well, 
> it uses zope:* ZCML directives. Are you going to fork plone.supermodel? 

I would be very tempted at least. Or decide to not use supermodel.

Wichert.

-- 
Wichert Akkerman It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Paul Everitt]

On Dec 22, 2008, at 6:36 AM, Martin Aspeli wrote:

> Chris (and Agendaless) is of course free to do whatever he wants with
> BFG. And as I've shown many times, I'm very supportive of the great  
> work
> coming out of the Repoze project.
>
> However, if Repoze is aiming to bridge the gap between the mature Zope
> components and the WSGI-enabled world of other Python frameworks and
> tools, then we should at least debate when the pendulum swings further
> away from Zope.

Repoze != BFG.  Chris didn't change a single thing in Repoze itself.

>> Everybody wins.
>
> I'm not quite sure about this. Anyone who wants to use traditional  
> Zope
> packages that are configured using the standard zope ZCML stuff in a  
> BFG
> application now has to contend with two methods of configuration that
> look identical but for an xmlns line at the top of the ZCML file, but
> are implemented in different places. That sounds like a recipe for
> confusion (especially considering that there is a reasonable amount of
> documentation and doctests out there that refer to the "old" way). It
> also sounds really hard to debug if ever there's a conflict between  
> the
> two types of handlers.

Some people want to use BFG but aren't after "fidelity to the Zope3  
megaframework".  These people should not pay a tax.  Remember, Zope3  
assumes a ZODB.  BFG doesn't even include ZODB.

People whose goal includes using existing Zope3 packages have to do  
some work.  Sure, they'll get a different flavor of adapters, but that  
makes sense: they behave differently!  Chris explained this, and you  
don't want to discuss this, so I'll conclude that this discussion is  
meta and not technical.

People who want to use ToscaWidgets (like me) have to do some work,  
too.  That's part of the Zen of BFG: it leaves out a LOT.  You only  
pay for what you eat, and we don't want to pay for trusted adapters.

"Only pay for what you eat" isn't your goal.  It's ok for new projects  
to start up and tackle fresh ideas and go in new directions.

>> Repoze != BFG
>
> This is certainly true. However, we've seen that a desire to do
> something in BFG (prune dependencies by replacing a core Zope package
> with a homespun version with tighter dependency control) had a knock- 
> on

Please list the cases where BFG has forced an inappropriate change on  
Repoze.

> effect on transitive dependencies in the Repoze world, which in turn
> impacts other users of those packages. The change in Chameleon meant
> that Repoze lost a few dependencies it didn't need, and Plone gained a
> few (or at least one) it didn't need.

The change meant Chameleon lost dependencies and *huge swaths of side- 
effect-ful, harmful* policy that it didn't need.

Chameleon doesn't exist solely for Plone, I believe.  Chameleon users  
are now the beneficiary of Chris's work to make a smaller, less side- 
effect-ful Chameleon.  This served Chameleon's purpose, which is to be  
bigger than Plone/Zope.  He also did extra work to make it easy to  
sign up for the Zope assumptions.

Everybody wins, including non-Plone users.  They count too. [wink]

> This is what I meant about BFG becoming a monolith: not that it's not
> built from reusable packages, but rather that if you want to control  
> the
> transitive dependencies like this, you're going to have to re- 
> implement

Remember, each time you want to say "transitive dependencies", you  
should replace it with the more accurate "harmful side-effects".

> any part of zope.* or plone.* or other users of the traditional ZCML  
> way
> of configuring the CA, with repoze.* equivalents that are not thus
> polluted.

True.  But so what?  Those packages presume a pile of assumptions that  
shouldn't be shoved down the throat of every possible BFG user.  BFG  
doesn't provide the packages they assume, so they wouldn't work  
anyway.  It's up to the person whose goals include plone.supermodel to  
sign up for the side effects.

I think your vision that any plone.* package should work in BFG is the  
flaw here.  That's not the vision of BFG.  plone.* packages are  
designed, I believe, for sharing with other packages atop the Zope3  
application server.

BFG is not atop the Zope3 application server.  Perhaps that part is  
unclear.  We're like most people: when it is convenient to grab  
something, BFG will.  If the pain is too high, then no.  Rational  
behavior.

> If you want to pull in, say, plone.supermodel (a "pure Zope 3" package
> that should be re-usable and may be useful to BFG if it ever wants to

BFG would never, ever, never have a goal of "serialize Zope 3  
schemas".  It doesn't include Zope 3 schemas.  It doesn't include the  
*concept* of schemas!!

However, some BFG user might want plone.supermodel.  Some Pylons user  
might want plone.supermodel.  In either case, the integration task  
falls on the integrator, not the destination framework.

The integrator is responsible for including the packages that  
supermodel wants, which include

Re: [Repoze-dev] bfg zcml directives...

[Chris McDonough]

Martin Aspeli wrote:

> repoze.zcml is a symptom that an improvement is needed further down the 
> stack. In the Plone world, we've learned the hard way that rolling your 
> own to avoid having to push something deeper into the stack is a costly 
> strategy in the long run. Paul should certainly know this. :) It may be 
> that Repoze should take a bit more pain now, in the form of writing a 
> proposal and putting up with some flak or politicking, to save having to 
> maintain a growing amount of custom code later. Or not. But at least 
> let's not give up before we've tried.

I personally won't be doing any politicking.

If someone wants to create a proposal and float it on zope-dev,  I'd participate
in the discussion and if it got approved, the implementation.  If that worked
satisfactorily, I'd decommission repoze.zcml.

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Martin Aspeli]

Wichert Akkerman wrote:
> Previously Martin Aspeli wrote:
>> If you want to pull in, say, plone.supermodel (a "pure Zope 3" package 
>> that should be re-usable and may be useful to BFG if it ever wants to 
>> serialise Zope 3 schema interfaces to/from an XML representation) well, 
>> it uses zope:* ZCML directives. Are you going to fork plone.supermodel? 
> 
> I would be very tempted at least. Or decide to not use supermodel.

Which would mean that the BFG-intersecting parts of the repoze stack 
would be a fork or re-implementation of all Zope stuff that was 
interesting to it. I don't think that's a sustainable way forward. Or at 
least, then repoze should stop billing itself as "the maturity of Zope 
now with the flexibility of the WSGI future".

But I don't think that's what Paul or Chris would want. :)

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin Aspeli wrote:
> Wichert Akkerman wrote:
>> Previously Martin Aspeli wrote:
>>> If you want to pull in, say, plone.supermodel (a "pure Zope 3" package 
>>> that should be re-usable and may be useful to BFG if it ever wants to 
>>> serialise Zope 3 schema interfaces to/from an XML representation) well, 
>>> it uses zope:* ZCML directives. Are you going to fork plone.supermodel? 
>> I would be very tempted at least. Or decide to not use supermodel.
> 
> Which would mean that the BFG-intersecting parts of the repoze stack 
> would be a fork or re-implementation of all Zope stuff that was 
> interesting to it. I don't think that's a sustainable way forward. Or at 
> least, then repoze should stop billing itself as "the maturity of Zope 
> now with the flexibility of the WSGI future".
> 
> But I don't think that's what Paul or Chris would want. :)

BFG != repoze.

BFG makes no promises that any Zope-derived software will work with it
out of the box.  BFG is a way to build Zope-like appplications without
carrying forward BBB-encrufted legacy.  BBB is "not your father's
Oldsmobile."

Plone will never run on BFG, period.


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

iD8DBQFJT9tL+gerLs4ltQ4RAkxeAJwKZjpBusQQsFsWplXxtF6lw67jLgCfbWYW
53xdV42yfLnpe+8XMlkTaDE=
=JAWF
-END PGP SIGNATURE-
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Martin Aspeli]

Paul Everitt wrote:
> On Dec 22, 2008, at 6:36 AM, Martin Aspeli wrote:
> 
>> Chris (and Agendaless) is of course free to do whatever he wants with
>> BFG. And as I've shown many times, I'm very supportive of the great  
>> work
>> coming out of the Repoze project.
>>
>> However, if Repoze is aiming to bridge the gap between the mature Zope
>> components and the WSGI-enabled world of other Python frameworks and
>> tools, then we should at least debate when the pendulum swings further
>> away from Zope.
> 
> Repoze != BFG.  Chris didn't change a single thing in Repoze itself.

Mmm... Chameleon is not in the repoze.* namespace, but it's in the 
Repoze repository, so if that's the definition of "Repoze" then he did.

> People whose goal includes using existing Zope3 packages have to do  
> some work.  Sure, they'll get a different flavor of adapters, but that  
> makes sense: they behave differently!  Chris explained this, and you  
> don't want to discuss this, so I'll conclude that this discussion is  
> meta and not technical.

It's absolutely about policy and roadmap, if that's what you mean by "meta".

>>> Repoze != BFG
>> This is certainly true. However, we've seen that a desire to do
>> something in BFG (prune dependencies by replacing a core Zope package
>> with a homespun version with tighter dependency control) had a knock- 
>> on
> 
> Please list the cases where BFG has forced an inappropriate change on  
> Repoze.

I think the fact that Chameleon now uses repoze.zcml may be. And my 
argument is that if you want to both use other parts of the Repoze stack 
that use the Zope 3 CA, and you want this minimal set of dependencies, 
then you're going to have to make the same change to all of those, which 
means that all other users of those packages have to live with the two 
ways of configuring components. That may be inappropriate. At least I 
think it deserves some serious consideration, not at least given how 
integration-oriented the Repoze stack tries to be.

> Everybody wins, including non-Plone users.  They count too. [wink]

My point is not specific to Plone, even though that's obviously where 
I'm coming from. Anyone who wants to use existing Zope packages with BFG 
or Chameleon now have two means of configuring ZCA components in their 
stack.

And this policy means that BFG (and maybe more of the Repoze stack, if 
it's a direct dependency of BFG) has now effectively written itself out 
of using *any* zope.* package bar the most basic ones that don't use 
ZCML in the zope:* namespace. That's a very small set of Zope packages. 
And potentially it's a growing list of packages that will need to 
be-implemented or forked for Repoze's needs.

I guess I'm saying if I owned BFG, I'd make a different trade-off. I'm 
not telling you to do what I would do, though I think it's incorrect to 
say that "everybody wins" by this.

> Remember, each time you want to say "transitive dependencies", you  
> should replace it with the more accurate "harmful side-effects".

Mmm I'm not sure they're quite so harmful, although I agree that 
trusted adapters are a bit weird. Would they actually break a BFG app if 
used, or is it just that you haven't thought about using them? And is it 
worse to give people the possibility of (ab)using them in a BFG app than 
to fork Zope's configuration machinery? Maybe. Maybe not.

> I think your vision that any plone.* package should work in BFG is the  
> flaw here.  That's not the vision of BFG.  plone.* packages are  
> designed, I believe, for sharing with other packages atop the Zope3  
> application server.

Sure. It was just an example, though, to illustrate that BFG apparently 
doesn't want almost anything of zope.* (bad grammar). That wasn't 
obvious to me. If that's the intention, then that's of course perfectly 
fine, although it makes BFG less attractive to me, personally, because 
it means I'm dependent on a smaller community of maintainers and users. 
Again, not a criticism, just an observation and a data point.

But, as we've seen, this policy almost by necessity has to be pushed 
down into other repoze.* packages where they straddle the worlds of the 
ZCA and BFG. Since a lot of the Repoze project's effort is going into 
BFG these days, that seems like a logical conclusion. Again, this may 
make future and current repoze.* packages less attractive to Plone and 
other users who want more of zope.*. Again, not a criticism, just an 
observation.

Although here is a slight criticism: Plone trunk is (probably) in the 
process of adopting Chameleon. I'd argue that repoze.zcml is not really 
an appropriate dependency for Plone, or at least one we'd rather avoid 
if we could. Yet here a BFG-driven decision meant that Plone now has to 
swallow this dependency, and there doesn't seem to be a lot of 
consideration that this could be a valid point of view. If Malthe's 
happy with this, I'll shut up and write some documentation to tell 
people that the bfg:adapter/utility/what

Re: [Repoze-dev] bfg zcml directives...

[Chris McDonough]

Martin Aspeli wrote:
> Wichert Akkerman wrote:
>> Previously Martin Aspeli wrote:
>>> If you want to pull in, say, plone.supermodel (a "pure Zope 3" package 
>>> that should be re-usable and may be useful to BFG if it ever wants to 
>>> serialise Zope 3 schema interfaces to/from an XML representation) well, 
>>> it uses zope:* ZCML directives. Are you going to fork plone.supermodel? 
>> I would be very tempted at least. Or decide to not use supermodel.
> 
> Which would mean that the BFG-intersecting parts of the repoze stack 
> would be a fork or re-implementation of all Zope stuff that was 
> interesting to it. I don't think that's a sustainable way forward. Or at 
> least, then repoze should stop billing itself as "the maturity of Zope 
> now with the flexibility of the WSGI future".
> 
> But I don't think that's what Paul or Chris would want. :)

BFG is a bit sideways to the goals of "the Repoze stack" (which is actually what
that tag line refers to, rather than BFG).  If I had it to do all over again,
"repoze.bfg" would be named just "BFG" (without the "repoze").  I doubt it's
possible to make this change now, apologies, folks will just have to understand.

Please try to make the mental jump required to separate WSGI middleware and
libraries labeled "repoze" (like repoze.errorlog, repoze.tm, repoze.squeeze,
repoze.monty, etc.) and BFG itself.  Conflation of BFG with the rest of the
repoze stack that is explicitly meant to be middleware and libraries is a 
mistake.

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Paul Everitt]

On Dec 22, 2008, at 1:06 PM, Martin Aspeli wrote:

> Wichert Akkerman wrote:
>> Previously Martin Aspeli wrote:
>>> If you want to pull in, say, plone.supermodel (a "pure Zope 3"  
>>> package
>>> that should be re-usable and may be useful to BFG if it ever wants  
>>> to
>>> serialise Zope 3 schema interfaces to/from an XML representation)  
>>> well,
>>> it uses zope:* ZCML directives. Are you going to fork  
>>> plone.supermodel?
>>
>> I would be very tempted at least. Or decide to not use supermodel.
>
> Which would mean that the BFG-intersecting parts of the repoze stack
> would be a fork or re-implementation of all Zope stuff that was
> interesting to it. I don't think that's a sustainable way forward.  
> Or at
> least, then repoze should stop billing itself as "the maturity of Zope
> now with the flexibility of the WSGI future".

Demonstrably false.  Please list the Repoze components, particularly  
the ones Plone is using, that were affected by this change.

--Paul
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Chris McDonough]

Martin Aspeli wrote:
> Paul Everitt wrote:
>> On Dec 22, 2008, at 6:36 AM, Martin Aspeli wrote:
>>
>>> Chris (and Agendaless) is of course free to do whatever he wants with
>>> BFG. And as I've shown many times, I'm very supportive of the great  
>>> work
>>> coming out of the Repoze project.
>>>
>>> However, if Repoze is aiming to bridge the gap between the mature Zope
>>> components and the WSGI-enabled world of other Python frameworks and
>>> tools, then we should at least debate when the pendulum swings further
>>> away from Zope.
>> Repoze != BFG.  Chris didn't change a single thing in Repoze itself.
> 
> Mmm... Chameleon is not in the repoze.* namespace, but it's in the 
> Repoze repository, so if that's the definition of "Repoze" then he did.

OK, sue me, not my last comment. ;-)

Much of the argument here revolves around the fact that chameleon.core and
chameleon.zpt both *contain* ZCML.  Maybe neither should, given that they are
meant to be libraries useful outside of any particular framework.  If they did
not contain any ZCML, they would drop their dependency on zope.configuration,
and glue packages would need pick up the slack to configure them however they
chose. Maybe we can ask Malthe to make ZCML-based configuration of Chameleon a
documentation task rather than a software task.  That might be a far easier
thing to do than trying to reengineer the directives in zope.component, and it
would solve the problem of inappropriate dependencies in both directions.

- C

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Martin Aspeli]

Paul Everitt wrote:
> On Dec 22, 2008, at 1:06 PM, Martin Aspeli wrote:
> 
>> Wichert Akkerman wrote:
>>> Previously Martin Aspeli wrote:
 If you want to pull in, say, plone.supermodel (a "pure Zope 3"  
 package
 that should be re-usable and may be useful to BFG if it ever wants  
 to
 serialise Zope 3 schema interfaces to/from an XML representation)  
 well,
 it uses zope:* ZCML directives. Are you going to fork  
 plone.supermodel?
>>> I would be very tempted at least. Or decide to not use supermodel.
>> Which would mean that the BFG-intersecting parts of the repoze stack
>> would be a fork or re-implementation of all Zope stuff that was
>> interesting to it. I don't think that's a sustainable way forward.  
>> Or at
>> least, then repoze should stop billing itself as "the maturity of Zope
>> now with the flexibility of the WSGI future".
> 
> Demonstrably false.  Please list the Repoze components, particularly  
> the ones Plone is using, that were affected by this change.

Paul, I'm not sure if you're just being facetious now... I've listed it 
in every email in this thread, and it's getting a bit irritating having 
to repeat it. Plone uses Chameleon. Chameleon is in the Repoze 
repository. Chris changed Chameleon. Plone is affected. If there are 
parallels with Chameleon (things that BFG want to use, that use the ZCA 
and depend on Zope 3's standard ZCML handling) then those will 
necessarily need to follow the same path. This may make those packages 
less attractive re-use in Zope 3-dependent projects and I think we 
should at least acknowledge that.

Plone is starting to embrace the Repoze stack in a big way. I don't 
think it's unreasonable of us to want to investigate the motives behind 
the people working on Repoze to understand how the Repoze development 
roadmap may affect Plone in the future.

So, here's what I've learned, and correct me if I'm wrong:

  - BFG does not intend to be part of the "Repoze" stack quite in the 
way that Repoze is trying to bridge the Zope and WSGI/Python worlds. 
This wasn't clear to me, but then I've never claimed to be deep into BFG 
either.

  - BFG has little interest in re-using the various zope.* packages 
beyond the very core zope.interface and zope.component.

  - Where BFG does want such a package, it may need to fork or 
re-implement it to avoid a transitive dependency on zope.security and 
friends. This is a trade-off the BFG developers are willing to make for 
the sake of a smaller dependency graph and less code in the stack that 
doesn't work well with BFG if used.

  - There may be a conflict of interest where a BFG dependency that uses 
the ZCA is re-used outside BFG, because of the different ways to 
configure components. This is something we'll have to manage, I guess.

I am happy to leave it at that. It doesn't make me think that using 
repoze.zope2 and related middleware in Plone is a bad idea. I think the 
Chameleon change is a bit troubling, but Chris' suggestion to push the 
configuration further up in the stack, making it a documentation issue, 
is a good one IMHO.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Wichert Akkerman]

Previously Martin Aspeli wrote:
> Wichert Akkerman wrote:
> > Previously Martin Aspeli wrote:
> >> If you want to pull in, say, plone.supermodel (a "pure Zope 3" package 
> >> that should be re-usable and may be useful to BFG if it ever wants to 
> >> serialise Zope 3 schema interfaces to/from an XML representation) well, 
> >> it uses zope:* ZCML directives. Are you going to fork plone.supermodel? 
> > 
> > I would be very tempted at least. Or decide to not use supermodel.
> 
> Which would mean that the BFG-intersecting parts of the repoze stack 
> would be a fork or re-implementation of all Zope stuff that was 
> interesting to it.

I don't see that. That is just my personal opinion and might not hold
for anyone else here.

Zope packages have a tendency to pull in half the zope world and
introduce a lot of zcml and security that you almost never want in
a non-zope environment. Unfortunately there appears to be little will in
zope-dev to actively change that. That's a shame, since it it
drastically reducing the chance of zope technology being accepted and
used by others.

If reimplementing something is easy to do (which is generally true
considering we all have Zope's source) and allows you to drop all that
extra baggage that - why not?

Wichert.

-- 
Wichert Akkerman It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Martin Aspeli]

Wichert Akkerman wrote:

> If reimplementing something is easy to do (which is generally true
> considering we all have Zope's source) and allows you to drop all that
> extra baggage that - why not?

Because you have to maintain it forever. Of course, you may not mind 
doing that - it'll be a case-by-case thing.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Malthe Borch]

2008/12/23 Martin Aspeli :
> Because you have to maintain it forever. Of course, you may not mind
> doing that - it'll be a case-by-case thing.

The fundamental codebase of Zope 3 is rather stable I think. I don't
think it needs much maintainance. There's one thing I'd like to
change/maintain, which is to get rid of C-extensions that were
originally written for two reasons:

1) Python was not flexible/dynamic enough at the time
2) Zope's security-model requires awareness throughout the codebase

>From recent discussion on zope-dev I get the feeling that the Zope
project has gone into a maintainance-state and is no longer being
actively developed, besides third-party extensions.

If acquisition was the most problematic decision of Zope 2, then the
Zope 3 security machinery is the most problematic in Zope 3. The
reason is the same: it's everywhere.

Since the development of Zope 3 has effectively ceased, I think it's
natural that the fork started by Chris last year continues to grow and
eventually will take over completely (when necessary).

We all have different points of view and I think this thread
demonstrates very well why "eating what you like" is healthy for a
community, because we can live with internal unrest. You don't like
ZCML, don't use it. Not a fan of security proxies? Don't proxy your
objects.

\malthe
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg zcml directives...

[Malthe Borch]

2008/12/22 Martin Aspeli :
> I think the fact that Chameleon now uses repoze.zcml may be. And my
> argument is that if you want to both use other parts of the Repoze stack
> that use the Zope 3 CA, and you want this minimal set of dependencies,
> then you're going to have to make the same change to all of those, which
> means that all other users of those packages have to live with the two
> ways of configuring components. That may be inappropriate. At least I
> think it deserves some serious consideration, not at least given how
> integration-oriented the Repoze stack tries to be.

Chameleon no longer depends on repoze.zcml, or zope.configuration for
that matter. It does still attempt to look up translators as Zope
components, but it comes with a "default" configuration implemented as
a module-global Python dictionary.

\malthe
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev