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
Summary of messages to the zope-tests list.
Period Tue Sep 2 11:00:00 2008 UTC to Wed Sep 3 11:00:00 2008 UTC.
There were 5 messages: 5 from Zope Tests.
Tests passed OK
---
Subject: OK : Zope-2.8 Python-2.3.6 : Linux
From: Zope Tests
Date: Tue Sep 2 20:49:57 EDT 2008
URL:
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
Hi,
In my current SQLAlchemy / Zope-based design, I need the following:
- SQLAlchemy table definitions
- classes + mappers
- Zope interfaces
The problem with this design is that much data has to be defined twice, e.g.
the datatype varchar(50) should be represented by an interface with
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
You may wish to look at z3c.dobbin, though the issue I have found in my
own experimentation, is with association tables for many to many
relationships which throws in a wrench into this otherwise elegant
solution. There may be something to around this in future.
Hermann Himmelbauer wrote:
Hi,
Hey Hermann,
Hermann Himmelbauer wrote:
In my current SQLAlchemy / Zope-based design, I need the following:
- SQLAlchemy table definitions
- classes + mappers
- Zope interfaces
The problem with this design is that much data has to be defined twice, e.g.
the datatype varchar(50) should
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 Hermann,
I'm currently using ore.alchemist to map sqlalchemy tables to zope3
schemas. Ok, so I had to tweak a couple of stuff but the end result is
that I have objects which are mapped to rdbms tables via sqlalchemy and
I can use generic formlib forms which decreases my development time for
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
On Wed, Sep 03, 2008 at 02:43:31PM +0200, Hermann Himmelbauer wrote:
Hi,
In my current SQLAlchemy / Zope-based design, I need the following:
- SQLAlchemy table definitions
- classes + mappers
- Zope interfaces
The problem with this design is that much data has to be defined twice, e.g.
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
Am Mittwoch 03 September 2008 15:14:22 schrieb Martijn Faassen:
Hey Hermann,
Hermann Himmelbauer wrote:
In my current SQLAlchemy / Zope-based design, I need the following:
- SQLAlchemy table definitions
- classes + mappers
- Zope interfaces
The problem with this design is that
Am Mittwoch 03 September 2008 16:02:17 schrieb Brian Sutherland:
On Wed, Sep 03, 2008 at 02:43:31PM +0200, Hermann Himmelbauer wrote:
Hi,
In my current SQLAlchemy / Zope-based design, I need the following:
- SQLAlchemy table definitions
- classes + mappers
- Zope interfaces
The
-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
Hi there,
On Wed, Sep 3, 2008 at 4:34 PM, Hermann Himmelbauer [EMAIL PROTECTED] wrote:
[snip]
In megrok.rdb we've sketched out the reverse of your approach: derive
the Zope 3 schemas from the SQLAlchemy table definitions. This because
it's more easy to derive a basic schema from a table
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
Am Mittwoch 03 September 2008 17:30:23 schrieb Martijn Faassen:
Hi there,
On Wed, Sep 3, 2008 at 4:34 PM, Hermann Himmelbauer [EMAIL PROTECTED] wrote:
[snip]
In megrok.rdb we've sketched out the reverse of your approach: derive
the Zope 3 schemas from the SQLAlchemy table definitions.
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
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.
Besides loosing the dependency, this makes for happier folks
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 for
-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, what you say makes good sense. I will get agreement signed and
sent and off to Jim. I am much more optimistic than I have been for a
long time. This stuff has really been bothering me since I am
concerned about efficient wsgi virtual host deployments and zope is
unnecessarily heavy.
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
46 matches
Mail list logo
