On Wed, Sep 3, 2008 at 02:54, David Pratt <[EMAIL PROTECTED]> wrote:
> In any case I am interested in
> hearing from folks about what can or ought to be done or whether there
> is interest in this direction. Many thanks.
That the packages are too dependent on each other today, and that this
means
--On 3. September 2008 08:04:00 +0200 Lennart Regebro <[EMAIL PROTECTED]>
wrote:
On Wed, Sep 3, 2008 at 02:54, David Pratt <[EMAIL PROTECTED]> wrote:
In any case I am interested in
hearing from folks about what can or ought to be done or whether there
is interest in this direction. Many tha
Hi David,
David Pratt wrote:
> I am feeling increasing pressure and frustration to re-examine what I am
> doing. Zope has a wonderful code base but it is spread through many
> packages in the form of dependencies. As a result, a small app in a
> working z3 setup can start off at almost 50MB wh
Hi David
> Betreff: [Zope-dev] Dependencies and future of zope 3
>
> Hi there. I have been developing with zope3 for about 4 years
> and would like to see zope continue in a healthy way into the
> future. The last couple of years particularly have brought
> significant change in how we deploy
Hi Andreas
> Betreff: Re: [Zope-dev] Dependencies and future of zope 3
>
>
>
> --On 3. September 2008 08:04:00 +0200 Lennart Regebro
> <[EMAIL PROTECTED]>
> wrote:
>
> > On Wed, Sep 3, 2008 at 02:54, David Pratt
> <[EMAIL PROTECTED]> wrote:
>
Hi there,
Roger Ineichen wrote:
[snip]
> Is someone willing to help doing that task?
I'm very interested in this topic as well, especially from the
perspective of Grok of course.
There are many strategies to go ahead in doing this. I'll list just one
observation I've had here.
One observation
--On 3. September 2008 12:17:56 +0200 Roger Ineichen <[EMAIL PROTECTED]>
wrote:
My personal meaning is, we already have a component architecture
but we need to split it in a different way into reusable components.
Such a split could probably not be done earlier because we didn't
see all the us
Hi Andreas
> Betreff: Re: AW: [Zope-dev] Dependencies and future of zope 3
[...]
> Sounds like a task for someone to build a dependency graph in
> order to generate a visualization in order to figure out
> where to break the dependency chain.
Marius implemented such an incredible tool alread
Hi Martijn
> Betreff: Re: [Zope-dev] Dependencies and future of zope 3
>
> Hi there,
> Roger Ineichen wrote:
> [snip]
> > Is someone willing to help doing that task?
>
> I'm very interested in this topic as well, especially from
> the perspective of Gr
Hi Martin. The concern is building high volume applications using z3,
the memory footprint for virtual hosting, and the unnecessary code that
adds to burden of managing security. **I only want the code I use**.
I agree that the current situation does not stop folks from getting
things done but
Hi Roger. Great. I am willing to help with this. I understand the
politics of change and feel there is most likely less impetus for change
for those consuming packages as opposed to folks like yourself or I that
use zope 3 as our framework. This is something that has to happen. The
situation ha
Roger, you make excellent sense here. The other issue of course is the
testing setup. So there is potential to operate here on a few levels to
achieve something that makes much better sense for moving forward.
Roger Ineichen wrote:
> I think the cleanup isn't really needed for zope packages its
On Wed, Sep 3, 2008 at 8:40 AM, David Pratt <[EMAIL PROTECTED]> wrote:
> I am trying to avoid the need for selective forking that Chris has found
> necessary to make progress with bfg. I want to continue using zope [...]
+1 Experimental forks to help determine what refactoring need to be
done in
Hey Martijn. These are good ideas. I also find myself importing a
package for some interfaces which sort of sucks too and which there were
perhaps a better solution for.
Martijn Faassen wrote:
> Hi there,
> Roger Ineichen wrote:
> [snip]
>> Is someone willing to help doing that task?
>
> I'm v
Benji York wrote:
> On Wed, Sep 3, 2008 at 8:40 AM, David Pratt <[EMAIL PROTECTED]> wrote:
>
>> I am trying to avoid the need for selective forking that Chris has found
>> necessary to make progress with bfg. I want to continue using zope [...]
>
> +1 Experimental forks to help determine what re
Some high-level remarks:
I agree with your sentiments. I too would like to see Zope 3
technology become more usable for lightweight applications. I'd like
to see the existing code base evolve in that direction.
Unfortunately, Zope 3 evolved as a monolithic development tree.
Tendrils form
Hi Martijn. As a side note I have found immense value in the effort to
split out the grok packages as it is has been very useful in my own
development. I have been looking for you on irc to discuss this further
to create a grokcore.traverser package and another package to abstract
grok.Model (t
On Sep 3, 2008, at 3:57 AM, Martin Aspeli wrote:
>> I guess the simple solution is well it you don't like it, use the
>> another framework. Its not quite that simple since I am extremely
>> fond
>> of the CA architecture and have a strong desire to continue with it
>> in
>> some form or anothe
Hi Jim. Here is an idea I have that can help bring perspective and
change. I propose that if we had the efforts of a few developers to work
on a single reference application, and the eyes of others willing to
inspect the package we could all benefit.
The idea would be to make the reference appl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
> On Sep 3, 2008, at 3:57 AM, Martin Aspeli wrote:
>>> I guess the simple solution is well it you don't like it, use the
>>> another framework. Its not quite that simple since I am extremely
>>> fond
>>> of the CA architecture and h
On Wednesday 03 September 2008, David Pratt wrote:
> I am trying to avoid the need for selective forking that Chris has found
> necessary to make progress with bfg. I want to continue using zope since
> these things are a big factor for the factors I stated.
I do not think that this community is s
On Wed, Sep 03, 2008 at 12:50:06PM +0200, Andreas Jung wrote:
> --On 3. September 2008 12:17:56 +0200 Roger Ineichen <[EMAIL PROTECTED]>
> wrote:
>> My personal meaning is, we already have a component architecture
>> but we need to split it in a different way into reusable components.
>> Such a s
On Wed, Sep 03, 2008 at 08:18:11AM +0200, Andreas Jung wrote:
> --On 3. September 2008 08:04:00 +0200 Lennart Regebro <[EMAIL PROTECTED]>
> wrote:
>> That the packages are too dependent on each other today, and that this
>> means a base installation of Zope3 is too big is well known. So I
>> think
Previously Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jim Fulton wrote:
> > On Sep 3, 2008, at 3:57 AM, Martin Aspeli wrote:
> >>> I guess the simple solution is well it you don't like it, use the
> >>> another framework. Its not quite that simple since I am extremely
On Wednesday 03 September 2008, Martijn Faassen wrote:
> One observation is that the pattern of '.browser' subpackages tends to
> expand the dependency structure significantly. Often you want to use
> non-browser functionality and don't care about the UI that ships with
> .browser. At the same time
On Wed, Sep 3, 2008 at 11:41 AM, Stephan Richter
<[EMAIL PROTECTED]> wrote:
> For several packages we took the following approach. Most packages that have
> browser packages are in zope.app; for example, zope.app.folder (we did not
> convert this package yet). We then took the API and moved it to
On Wed, Sep 3, 2008 at 1:47 PM, Benji York <[EMAIL PROTECTED]> wrote:
> Maybe we should create a new namespace package for "browser" code.
>
> How about "zope.browser"?
Heh. That's just sooo long. Perhaps it should be "zobr". :-)
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which
Benji York wrote:
> On Wed, Sep 3, 2008 at 11:41 AM, Stephan Richter
> <[EMAIL PROTECTED]> wrote:
>
>> For several packages we took the following approach. Most packages that have
>> browser packages are in zope.app; for example, zope.app.folder (we did not
>> convert this package yet). We then to
On Wednesday 03 September 2008, Philipp von Weitershausen wrote:
> My general sentiment is against creating more structure than we already
> have. Flat is better than nested. IMHO it's perfectly ok to have the
> Python APIs in zope.foo and browser code in zope.app.foo. I think sooner
> than later p
Hi
> Betreff: Re: [Zope-dev] Dependencies and future of zope 3
>
> On Wed, Sep 3, 2008 at 11:41 AM, Stephan Richter
> <[EMAIL PROTECTED]> wrote:
>
> > For several packages we took the following approach. Most packages
> > that have browser pack
ckend + zope security + choice of traversal method (with publisher)
== interesting, productive, mature, dynamic and efficient.
On Wed, Sep 3, 2008 at 3:06 PM, Roger Ineichen <[EMAIL PROTECTED]> wrote:
> Hi
>
>> Betreff: Re: [Zope-dev] Dependencies and future of zope 3
>>
&g
On Wednesday 03 September 2008, David Pratt wrote:
> Hey Roger. Sounds reasonable to me. Can we also discuss the potential
> of only including testing setup for dev eggs and removing testing as
> part of a release when the eggs are packaged to pypi or other
> repository for consumption.
-1. Withou
Hi David
> Betreff: Re: [Zope-dev] Dependencies and future of zope 3
>
> Hey Roger. Sounds reasonable to me. Can we also discuss the
> potential of only including testing setup for dev eggs and
> removing testing as part of a release when the eggs are
> packaged to pypi o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Pratt wrote:
> Hey Roger. Sounds reasonable to me. Can we also discuss the potential
> of only including testing setup for dev eggs and removing testing as
> part of a release when the eggs are packaged to pypi or other
> repository for consumpti
be friendly to
>> wsgi with or without a zodb and show both sides of the coin -
>> that CA + choice of backend + zope security + choice of
>> traversal method (with publisher) == interesting, productive,
>> mature, dynamic and efficient.
>
> Sounds interesting but let
On Wednesday 03 September 2008, Tres Seaver wrote:
> I'm not volunteering to write it, but it strikes me as odd that folks
> haven't morphed zc.buildout (and / or associated recipes) to use this
> field. I *did* write a setuptools add on which saved the
> 'tests_require' info into the EGG_INFO dir
Stephan Richter wrote:
> On Wednesday 03 September 2008, David Pratt wrote:
>> I am trying to avoid the need for selective forking that Chris has found
>> necessary to make progress with bfg. I want to continue using zope since
>> these things are a big factor for the factors I stated.
>
> I do no
Hey,
On Wed, Sep 3, 2008 at 5:41 PM, Stephan Richter
<[EMAIL PROTECTED]> wrote:
[snip]
> Jim must have read your message with a big smile on his face. He was arguing
> for this approach of flat package names about 2-3 years ago and I shot that
> proposal down. I hate when I only realize design mis
Hi there,
On Wed, Sep 3, 2008 at 7:55 PM, Philipp von Weitershausen
<[EMAIL PROTECTED]> wrote:
> Benji York wrote:
[snip]
>> Maybe we should create a new namespace package for "browser" code.
>>
>> How about "zope.browser"?
>
> My general sentiment is against creating more structure than we alread
Roger Ineichen wrote:
[snip]
> Most packages which are interesting for reuse
> provide more or less only ZMI related views.
>
> What about zope.zmi if they provide views for
> the ZMI. This views are allmost unuseable
> outside the ZMI (know as Rotterdam skin)
Why not simply leave the ZMI stuff i
Hi there,
Roger Ineichen wrote:
[snip]
> We have different kind of refactorings which all solve some
> problems. I think we should not start with the browser views.
> There are some core dependencies we need to cleanup first.
>
> Right now I'm working forward with small refactorings
> which sol
Hi Martijn
> Betreff: Re: [Zope-dev] Dependencies and future of zope 3
>
> Roger Ineichen wrote:
> [snip]
> > Most packages which are interesting for reuse provide more or less
> > only ZMI related views.
> >
> > What about zope.zmi if they provide
David Pratt wrote at 2008-9-3 20:32 -0300:
>Can we also discuss the potential
>of only including testing setup for dev eggs and removing testing as
>part of a release when the eggs are packaged to pypi or other
>repository for consumption.
-1.
This would really only save disk space
--
Die
Andreas Jung wrote:
>
> This is a big issue? I don't think so. Disks are cheap and usually you
> don't get in touch with the dependent modules under the hood - except
> for debugging :-)
I don't agree. I think making the dependencies fewer would result is
easier re-use of bits of "zope", which
44 matches
Mail list logo