Martijn Faassen wrote:
> Jim Fulton wrote:
> [snip]
>> I'd rather leave zope.publsiher more or less alone, but develop a new
>> thing that has the basic/core functionality we need and refactor
>> zope.publisher to use that.
>
> I had the impression Shane was doing that; i.e. building zope.pip
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Shane Hathaway wrote:
> Jim Fulton wrote:
>> - It's not well enough documented. While I think there's merit in doing
>> some things at the WSGI level, I remain pretty happy with the
>> publication interface for separatating generic publisher functio
Hey,
Jim Fulton wrote:
[snip]
> I'd rather leave zope.publsiher more or less alone, but develop a new
> thing that has the basic/core functionality we need and refactor
> zope.publisher to use that.
I had the impression Shane was doing that; i.e. building zope.pipeline
factoring bits out of
Jim Fulton wrote:
> I'd rather leave zope.publsiher more or less alone, but develop a new
> thing that has the basic/core functionality we need and refactor
> zope.publisher to use that. I'd also like to use or be compatible with
> WebOb on that. I'd prefer to do this at PyCon where I'll have t
On Mar 6, 2009, at 2:18 AM, Shane Hathaway wrote:
> Jim Fulton wrote:
>> - It's not well enough documented. While I think there's merit in
>> doing some things at the WSGI level, I remain pretty happy with the
>> publication interface for separatating generic publisher functions
>> from ap
Jim Fulton wrote:
> - It's not well enough documented. While I think there's merit in doing
> some things at the WSGI level, I remain pretty happy with the
> publication interface for separatating generic publisher functions from
> application policies. I which the use of this API was better
On Feb 24, 2009, at 12:59 PM, Shane Hathaway wrote:
> Jim Fulton wrote:
>> I disagree strongly with many of the assertions made in these
>> articles. (I can't judge the pipeline proposal, since it is only
>> fleshed out in code.) While I do think zope.publisher has some
>> problems, the
On Wed, Feb 25, 2009 at 08:46, Baiju M wrote:
> This will not make any change in dependency graph unless zope.location
> become a namespace package.
Yeah, that was what I was thinking, but I just realized that it might
be tricky to have both a zope.location and a zope.location.interfaces.
I haven
Hi there,
In general splitting up interfaces from implementations would help
pluggability. That said, I'm not very much in favor of such a split up
of so many packages at the moment, as the case for pluggability will
need to be made first for each new package created.
I think we should focus o
Hanno Schlichting wrote:
> Martijn Faassen wrote:
>> Hanno, would you consider also generating graphs for the grokcore.* packages?
>
> Can you point me to a buildout or virtualenv-friendly way of getting an
> environment with those? Than it should be rather trivial to do for me.
I'm not sure what
On Wed, Feb 25, 2009 at 12:39 PM, Lennart Regebro wrote:
> On Wed, Feb 25, 2009 at 04:05, Shane Hathaway wrote:
>> Stephan Richter wrote:
>>> On Tuesday 24 February 2009, Shane Hathaway wrote:
Brainstorming deeper: we could apply a naming convention where the
specification package is na
On Wed, Feb 25, 2009 at 04:05, Shane Hathaway wrote:
> Stephan Richter wrote:
>> On Tuesday 24 February 2009, Shane Hathaway wrote:
>>> Brainstorming deeper: we could apply a naming convention where the
>>> specification package is named with the suffix "spec", so zope.location
>>> would be split
Stephan Richter wrote:
> On Tuesday 24 February 2009, Shane Hathaway wrote:
>> Brainstorming deeper: we could apply a naming convention where the
>> specification package is named with the suffix "spec", so zope.location
>> would be split into zope.location and zope.locationspec.
>
> what about zo
On Tuesday 24 February 2009, Shane Hathaway wrote:
> Brainstorming deeper: we could apply a naming convention where the
> specification package is named with the suffix "spec", so zope.location
> would be split into zope.location and zope.locationspec.
what about zope.ilocation?
Regards,
Stephan
Martijn Faassen wrote:
> Hey,
>
> On Tue, Feb 24, 2009 at 11:26 PM, Jim Fulton wrote:
> [snip]
>> The graph only shows direct dependencies on zope.i18n and zope.security, but
>> there are many other direct dependencies.
>
> Ah, agreed, yes, I think this is because of the transitive dependency
>
Martijn Faassen wrote:
> Hanno, would you consider also generating graphs for the grokcore.* packages?
Can you point me to a buildout or virtualenv-friendly way of getting an
environment with those? Than it should be rather trivial to do for me.
Hanno
Jim Fulton wrote:
> The graph only shows direct dependencies on zope.i18n and
> zope.security, but there are many other direct dependencies.
Right, that's what
http://hannosch.eu/dependencies/zope/zope.publisher-full.svg is for. Now
showing the full set of direct dependencies.
I find both the r
Hey,
On Tue, Feb 24, 2009 at 11:26 PM, Jim Fulton wrote:
[snip]
> The graph only shows direct dependencies on zope.i18n and zope.security, but
> there are many other direct dependencies.
Ah, agreed, yes, I think this is because of the transitive dependency
functionality removal somehow, even tho
On Feb 24, 2009, at 5:19 PM, Martijn Faassen wrote:
> Jim Fulton wrote:
>> On Feb 24, 2009, at 12:33 PM, Hanno Schlichting wrote:
>>> P.S. See http://hannosch.eu/dependencies/zope/zope.publisher.svg for
>>> the
>>> dependency graph ;)
>>
>>
>> That's cool, although wildly inaccurate.
>
> What's w
Jim Fulton wrote:
> On Feb 24, 2009, at 12:33 PM, Hanno Schlichting wrote:
>> P.S. See http://hannosch.eu/dependencies/zope/zope.publisher.svg for
>> the
>> dependency graph ;)
>
>
> That's cool, although wildly inaccurate.
What's wildly inaccurate about it? Missing transitive dependencies or
Jim Fulton wrote:
> Maybe, but I find that people confuse the machinery in zope.publisher
> with a bunch of additional and very confusing machinery in various
> zope.app packages. The publisher itself is pretty simple. I think
> this is illustrated by paste.txt in the zope.publisher package
On Feb 24, 2009, at 1:55 PM, Shane Hathaway wrote:
> Martijn Faassen wrote:
>> The main problem I have with the zope publication machinery is that
>> after all these years of using it I *still* get lost in it regularly.
>> A more regular architecture that can be traced more easily would not
>> on
On Feb 24, 2009, at 12:44 PM, Shane Hathaway wrote:
> Jim Fulton wrote:
>> On Feb 24, 2009, at 3:08 AM, Shane Hathaway wrote:
>>> I've been working on the dependencies to and from zope.publisher.
>>> Refining the dependencies should make it easier to integrate
>>> zope.pipeline when it's ready.
>
Martijn Faassen wrote:
> The main problem I have with the zope publication machinery is that
> after all these years of using it I *still* get lost in it regularly.
> A more regular architecture that can be traced more easily would not
> only allow better understanding on my part, but might also al
On Feb 24, 2009, at 12:33 PM, Hanno Schlichting wrote:
> P.S. See http://hannosch.eu/dependencies/zope/zope.publisher.svg for
> the
> dependency graph ;)
That's cool, although wildly inaccurate. One of the things wrong with
zope.publisher is that it depends on too many other things. It wou
Martijn Faassen wrote:
> Hanno Schlichting wrote:
> [snip]
>> P.S. See http://hannosch.eu/dependencies/zope/zope.publisher.svg for the
>> dependency graph ;)
>
> That's a cool resource! (the general dependencies folder there)
>
> Are you removing indirect dependencies before generating the graphs
Hey,
Shane Hathaway wrote:
[snip]
> After thinking this over last night, I realize that the idea to move
> BrowserView, BrowserPage, and TestRequest is driven by the desire to
> clarify the dependency graph. That's more complex than what I'm trying
> to do and I don't think I need to do that fo
Hi there,
Hanno Schlichting wrote:
[snip]
> P.S. See http://hannosch.eu/dependencies/zope/zope.publisher.svg for the
> dependency graph ;)
That's a cool resource! (the general dependencies folder there)
Are you removing indirect dependencies before generating the graphs? I
think it is valuable
Hey,
On Tue, Feb 24, 2009 at 6:39 PM, Jim Fulton wrote:
[Shane's blog entries]
> I disagree strongly with many of the assertions made in these articles. (I
> can't judge the pipeline proposal, since it is only fleshed out in code.)
> While I do think zope.publisher has some problems, they aren't
Jim Fulton wrote:
> I disagree strongly with many of the assertions made in these
> articles. (I can't judge the pipeline proposal, since it is only
> fleshed out in code.) While I do think zope.publisher has some
> problems, they aren't the same problems that shane sees.
What are the probl
Hey,
On Tue, Feb 24, 2009 at 6:33 PM, Stephan Richter
wrote:
> In general I am worried that we are creating too many packages. However, here
> is my order of importance:
>
> 1. Minimize dependencies.
> 2. Minimize packages.
+1
I think on the longer term better dependencies can allow us to remov
Jim Fulton wrote:
> On Feb 24, 2009, at 3:08 AM, Shane Hathaway wrote:
>
>> I've been working on the dependencies to and from zope.publisher.
>> Refining the dependencies should make it easier to integrate
>> zope.pipeline when it's ready.
>
> Can you elaborate on this a bit?
I've been discussin
On Feb 24, 2009, at 11:46 AM, Martijn Faassen wrote:
> Jim Fulton wrote:
>> On Feb 24, 2009, at 3:08 AM, Shane Hathaway wrote:
>>
>>> I've been working on the dependencies to and from zope.publisher.
>>> Refining the dependencies should make it easier to integrate
>>> zope.pipeline when it's read
Jim Fulton wrote:
> On Feb 24, 2009, at 11:12 AM, Tres Seaver wrote:
>> - - Using TestRequest involves pulling in all of zope.publisher, a
>> *big*
>> dependency; Shane wants to reduce such dependencies.
>
> OK, I don't agree that zope.publisher is a big dependency, especially
> for code tha
On Tuesday 24 February 2009, Martijn Faassen wrote:
> > Packages that depend on those classes usually more or less implicitly
> > depend on zope.publisher. So the split might be arbitrary for this
> > example.
>
> My understanding is that Shane is working on an alternative publisher,
> zope.pipelin
On Tuesday 24 February 2009, Jim Fulton wrote:
> > - - Using TestRequest involves pulling in all of zope.publisher, a
> > *big*
> > dependency; Shane wants to reduce such dependencies.
>
> OK, I don't agree that zope.publisher is a big dependency, especially
> for code that is meant to run in
On Feb 24, 2009, at 11:12 AM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jim Fulton wrote:
>> On Feb 24, 2009, at 9:26 AM, Tres Seaver wrote:
>> ...
As for TestRequest, I could update the setup.py of various packages
that
currently depend on zope.publi
Stephan Richter wrote:
> On Tuesday 24 February 2009, Shane Hathaway wrote:
>> I've noticed that nearly all packages that depend on zope.publisher
>> depend only on a few pieces of it:
>>
>>- zope.publisher.interfaces
>
> Can you give examples?
>
>>- zope.publisher.browser.Browser{View|Pa
Jim Fulton wrote:
> On Feb 24, 2009, at 3:08 AM, Shane Hathaway wrote:
>
>> I've been working on the dependencies to and from zope.publisher.
>> Refining the dependencies should make it easier to integrate
>> zope.pipeline when it's ready.
>
> Can you elaborate on this a bit?
He has, though perh
Hey Shane,
+1 on separating out zope.publisher.interfaces, as it seems low-hanging
fruit.
Shane Hathaway wrote:
> It is less clear what we should do with BrowserView and BrowserPage.
> They depend on zope.location, unlike the rest of zope.publisher, so they
> don't really fit there. Perhaps t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
> On Feb 24, 2009, at 9:26 AM, Tres Seaver wrote:
> ...
>>> As for TestRequest, I could update the setup.py of various packages
>>> that
>>> currently depend on zope.publisher just for TestRequest. I would
>>> make
>>> zope.publi
On Tuesday 24 February 2009, Shane Hathaway wrote:
> I've noticed that nearly all packages that depend on zope.publisher
> depend only on a few pieces of it:
>
> - zope.publisher.interfaces
Can you give examples?
> - zope.publisher.browser.Browser{View|Page}
>
> - zope.publisher.browser.
On Feb 24, 2009, at 9:26 AM, Tres Seaver wrote:
...
>> As for TestRequest, I could update the setup.py of various packages
>> that
>> currently depend on zope.publisher just for TestRequest. I would
>> make
>> zope.publisher a test-only requirement.
>
> Frankly, any code using a testing stub
On Feb 24, 2009, at 3:08 AM, Shane Hathaway wrote:
> I've been working on the dependencies to and from zope.publisher.
> Refining the dependencies should make it easier to integrate
> zope.pipeline when it's ready.
Can you elaborate on this a bit?
> I've noticed that nearly all packages that de
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Shane Hathaway wrote:
> I've been working on the dependencies to and from zope.publisher.
> Refining the dependencies should make it easier to integrate
> zope.pipeline when it's ready.
>
> I've noticed that nearly all packages that depend on zope.p
I've been working on the dependencies to and from zope.publisher.
Refining the dependencies should make it easier to integrate
zope.pipeline when it's ready.
I've noticed that nearly all packages that depend on zope.publisher
depend only on a few pieces of it:
- zope.publisher.interfaces
46 matches
Mail list logo
