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
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
--
Dieter
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 not think
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
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 already
have. Flat
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 in
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 views for the ZMI. This
views are
allmost unuseable
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 a
--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
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 while
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 zope
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:
In any case I am interested in
hearing from folks about what
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
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 already.
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 Grok of course.
That whould be great. I'll let you
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
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
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 very
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 refactoring
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
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
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 another into the
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
-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 have a strong
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 so
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 split
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 I can
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
fond
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. fdrake at gmail.com
Chaos is the score
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 took the API
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
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 packages are in zope.app; for example,
zope.app.folder (we
+ 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
On Wed, Sep 3, 2008 at 11:41 AM
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. Without
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 or other repository
-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 consumption.
, Roger Ineichen
[EMAIL PROTECTED] wrote:
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 packages
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
43 matches
Mail list logo
