Re: [Zope-dev] [Checkins] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3
Previously Dan Korostelev wrote: 2009/2/24 Shane Hathaway sh...@hathawaymix.org: Log message for revision 97183: New library for OpenID auth in Zope 3 Changed: A zope.app.openidconsumer/ Wow, that's great! Finally an OpenID auth plugin is being developed! plone.openid has been out since August 2007, so it's hardly the first OpenID auth implementation for Zope.. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3
Wow, that's great! Finally an OpenID auth plugin is being developed! plone.openid has been out since August 2007, so it's hardly the first OpenID auth implementation for Zope.. Well, yeah, but plone.openid uses Zope2 and Plone PAS while this is a pure zope3 solution. However I'd like to see parts that are neither zmi-specific nor plone-specific to be refactored to a separate package. The ZopeStore from plone.openid, for example :-) -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.jsonrpc relase
Roger Ineichen wrote: does someone have a good idea how we can handle an Unauthorized error with JSON-RPC? Should we use an error view concept and include a JavaScript method which can handle a special error code/message from the server and show a kind if login form? Any hints or does somebody know a framework which supports such an implementation? Hi Roger Here's a hint I've been looking at. Maybe it will give you some ideas. http://ajaxpatterns.org/Direct_Login - Jim Washington ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: z3c.mimetype/ Create infrastructure for z3c.mimetype
On Tue, Feb 24, 2009 at 8:29 AM, Dan Korostelev nad...@gmail.com wrote:
2009/2/24 Baiju M mba...@zeomega.net:
Hi Dan,
On Tue, Feb 24, 2009 at 6:40 PM, Dan Korostelev nad...@gmail.com wrote:
Log message for revision 97207:
Create infrastructure for z3c.mimetype
Changed:
A z3c.mimetype/
I thought of sharing this with you, may be useful. I have got one tip from
Jim for creating a new project area:
http://mail.zope.org/pipermail/zope3-dev/2006-October/020701.html
Heh, nice trick with `z` :) Thank you.
A slight refinement:
svn mkdir path-to-repo/new-project{,trunk,tags,branches}
Using the `z` trick, that would be:
svn mkdir `z`/new-project{,trunk,tags,branches}
--
Benji York
Senior Software Engineer
Zope Corporation
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: z3c.mimetype/ Create infrastructure for z3c.mimetype
2009/2/24 Benji York be...@zope.com:
On Tue, Feb 24, 2009 at 8:29 AM, Dan Korostelev nad...@gmail.com wrote:
2009/2/24 Baiju M mba...@zeomega.net:
Hi Dan,
On Tue, Feb 24, 2009 at 6:40 PM, Dan Korostelev nad...@gmail.com wrote:
Log message for revision 97207:
Create infrastructure for z3c.mimetype
Changed:
A z3c.mimetype/
I thought of sharing this with you, may be useful. I have got one tip from
Jim for creating a new project area:
http://mail.zope.org/pipermail/zope3-dev/2006-October/020701.html
Heh, nice trick with `z` :) Thank you.
A slight refinement:
svn mkdir path-to-repo/new-project{,trunk,tags,branches}
Using the `z` trick, that would be:
svn mkdir `z`/new-project{,trunk,tags,branches}
Thanks! BTW, there tips are probably useful enough to be included to
zope3docs' development section. :)
--
WBR, Dan Korostelev
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
-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.publisher
depend only on a few pieces of it:
- zope.publisher.interfaces
- zope.publisher.browser.Browser{View|Page}
- zope.publisher.browser.TestRequest
One simple, low-risk refactoring I would like to do is move
zope.publisher.interfaces into its own package, make zope.publisher a
namespace package, and make zope.publisher depend on
zope.publisher.interfaces. The __init__.py in zope.publisher is already
empty, so I expect the namespace conversion to be safe. Then I'd like
to refine the dependency list of various packages that only require
zope.publisher.interfaces. Any objections?
+1.
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 those two belong in a new package,
zope.publisher.browserbase. There is also the tiny new zope.browser
package. Would it make sense to move them there? (It's hard to tell
what the intent of the new package is.) I'd love to hear other suggestions.
zope.browser is supposed to be a zero-dependency spot for commonly-used
interfaces:
This package provides shared zope browser components without other
dependencies.
So I wouldn't move anything depending on zope.location into that
package. Your new package idea sounds better.
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 which is that heavyweight needs
to be refactored.
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJpAOY+gerLs4ltQ4RAjp/AJ9sbBrxvOrWkjFuypP7/16n75uUkwCgvtZW
3J0s+vDo0p1nxkxhtrFbS/A=
=FUZq
-END PGP SIGNATURE-
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: z3c.mimetype/ Create infrastructure for z3c.mimetype
On Feb 24, 2009, at 8:53 AM, Dan Korostelev wrote:
2009/2/24 Benji York:
On Tue, Feb 24, 2009 at 8:29 AM, Dan Korostelev wrote:
Heh, nice trick with `z` :) Thank you.
A slight refinement:
svn mkdir path-to-repo/new-project{,trunk,tags,branches}
Using the `z` trick, that would be:
svn mkdir `z`/new-project{,trunk,tags,branches}
Thanks! BTW, there tips are probably useful enough to be included to
zope3docs' development section. :)
Or even one character shorter, (plus no need to create a script, put
it in the path and make it executable)
:-)
svn mkdir $Z/new-project{,trunk,tags,branches}
where Z is an environment variable in your .profile (or .bash_profile)
Z=svn+ssh://svn.zope.org/repos/main
export Z
or .login for C shell users
setenv Z svn+ssh://svn.zope.org/repos/main
Do we need to put a disclaimer that for the shortcut shown above the
shell needs to support brace expansion -- the output of ``set -o``
should have ``braceexpand on``.
Most of the modern Bourne-derived shells do have it and it's on by
default. The C shell has always had it AFAIK. A user could switch it
off in both shell kinds.
I guess that would be too much detail.
:-)
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Review of zc.dict tlotze-blist branch
[Thomas asked me to review his zc.dict branch a while ago.] Hi Thomas. Thank you for this work. It looks great. I do have several comments below (from an abbreviated diff against the current trunk). Index: buildout.cfg === --- buildout.cfg (.../trunk) (revision 97211) +++ buildout.cfg (.../branches/tlotze-blist) (revision 97211) @@ -2,11 +2,10 @@ develop = . parts = test py -find-links = http://download.zope.org/distribution/ - [test] recipe = zc.recipe.testrunner -eggs = zc.dict +eggs = zc.dict [generations] +defaults = [-v, -c] I don't think the generations code should be required, and (since you used extras_require) neither do you. Therefore I'd prefer it if the main tests also didn't depend on that code. The way I've done this with other packages (e.g. http://svn.zope.org/zc.async/trunk/buildout.cfg?view=auto) is to have multiple test sections (with different names). The downside is that then, to run all possible tests, you have to run more than one command. The upside is that arguably the most important configuration--the base one--is truly tested. [py] recipe = zc.recipe.egg Index: CHANGES.txt === --- CHANGES.txt (.../trunk) (revision 97211) +++ CHANGES.txt (.../branches/tlotze-blist) (revision 97211) @@ -1,3 +1,8 @@ +1.3 (unreleased) + + +* changed the implementation of OrderedDict to store the order in buckets I suggest adding via zc.blist or something like that. ... Index: src/zc/dict/configure.zcml === --- src/zc/dict/configure.zcml (.../trunk) (revision 0) +++ src/zc/dict/configure.zcml (.../branches/tlotze-blist) (revision 97211) @@ -0,0 +1,5 @@ +configure xmlns=http://namespaces.zope.org/zope; + + include package=.generations / + +/configure configure.zcml has a semantic of always include. Because the generations code may not work for many people (as we've discussed before, and see comment in evolve test below), I'd prefer that the generations code have a semantic of optionally include. Therefore, I suggest you rename this to generations.zcml or something like that. ... Index: src/zc/dict/dict.py === --- src/zc/dict/dict.py (.../trunk) (revision 97211) +++ src/zc/dict/dict.py (.../branches/tlotze-blist) (revision 97211) ... def __setitem__(self, key, value): -delta = 1 -if key in self._data: -delta = 0 -self._data[key] = value -if delta: +if key not in self._data: self._order.append(key) -self._len.change(delta) +self._len.change(1) +self._data[key] = value Nice improvement in readability. def updateOrder(self, order): ... Also as mentioned before on the Zope list, until this API is deprecated in favor of one that encourages more granular changes, the change to blist only really helps the story for adding new items to an ordered dict. The Plone IExplicitOrdering interface looks reasonable, and could really take advantage of the blist characteristics. http://dev.plone.org/plone/browser/plone.folder/trunk/plone/folder/interfaces.py Index: src/zc/dict/generations/evolve1.txt === --- src/zc/dict/generations/evolve1.txt (.../trunk) (revision 0) +++ src/zc/dict/generations/evolve1.txt (.../branches/tlotze-blist) ... As we discussed earlier, findObjectsMatching will miss OrderedDicts that are used as internal data structures. I regard that as a primary use case for this package, so IMO that's important to note in the doc and in the Python file. Otherwise, looks great to me. Thank you! Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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 depend on zope.publisher
depend only on a few pieces of it:
- zope.publisher.interfaces
- zope.publisher.browser.Browser{View|Page}
- zope.publisher.browser.TestRequest
I'd like to turn this around a little bit. Only browser-based code
should depend on zope.publisher. This seems like a very reasonable
dependency. It's like wxwindows UI code depending on wxwindows.
Maybe the browser code should be factored out of the packages that
depend on zoep.publisher so that only *that* code has the dependency
and non-browser code doesn't.
Jim
--
Jim Fulton
Zope Corporation
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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 which is that heavyweight needs to be refactored. There's nothing all that heavyweight about TestRequest. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.jsonrpc relase
Hi Jim Betreff: Re: [Zope-dev] z3c.jsonrpc relase Roger Ineichen wrote: does someone have a good idea how we can handle an Unauthorized error with JSON-RPC? Should we use an error view concept and include a JavaScript method which can handle a special error code/message from the server and show a kind if login form? Any hints or does somebody know a framework which supports such an implementation? Hi Roger Here's a hint I've been looking at. Maybe it will give you some ideas. http://ajaxpatterns.org/Direct_Login Thanks a lot for the hint. Regards Roger Ineichen _ END OF MESSAGE - Jim Washington ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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.TestRequest
Packages that depend on those classes usually more or less implicitly depend
on zope.publisher. So the split might be arbitrary for this example.
One simple, low-risk refactoring I would like to do is move
zope.publisher.interfaces into its own package, make zope.publisher a
namespace package, and make zope.publisher depend on
zope.publisher.interfaces. The __init__.py in zope.publisher is already
empty, so I expect the namespace conversion to be safe. Then I'd like
to refine the dependency list of various packages that only require
zope.publisher.interfaces. Any objections?
I want to see some motivation, because I fail to see how this helps.
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 those two belong in a new package,
zope.publisher.browserbase.
I do agree moving BrowserView and BrowserPage out of the publisher because
they introduce the zope.location dependency.
There is also the tiny new zope.browser
package. Would it make sense to move them there? (It's hard to tell
what the intent of the new package is.) I'd love to hear other
suggestions.
I think the purpose of the package is still defining itself. I think it will
be defined by the things that we move into it. I am very tempted to say that
it is a good home for BrowserView and BrowserPage.
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.
TestRequest does not add any additional dependencies to the system, so what's
the point? It will depend on zope.publisher.browser anyways.
Regards,
Stephan
--
Stephan Richter
Web Software Design, Development and Training
Google me. Zope Stephan Richter
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
-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.publisher a test-only requirement. Frankly, any code using a testing stub which is that heavyweight needs to be refactored. There's nothing all that heavyweight about TestRequest. - - It derives from BrowserRequest, which means carrying along a *lot* of extra implementation baggage. Tests which use this class, rather than stubbing out a dummy request which provides only the API required by the application-under-test, will tend to grow unexpected / undesirable tentacles to the request implementation. - - Using TestRequest involves pulling in all of zope.publisher, a *big* dependency; Shane wants to reduce such dependencies. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJpBxw+gerLs4ltQ4RAosKAKDNmJoShgxtFrhi3rVFYqa3H+ncVACgmGU8 TOcde0xx65K1KeIopuy3hpk= =/+UR -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3
Shane Hathaway wrote: Log message for revision 97183: New library for OpenID auth in Zope 3 Changed: A zope.app.openidconsumer/ One question: why is this in zope.app? I think there's a consensus we're trying to pull as much from zope.app as possible. Is this going to provide a ZMI UI at all? If not, I'd suggest putting it in zope.* Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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 those two belong in a new package, zope.publisher.browserbase. There is also the tiny new zope.browser package. Would it make sense to move them there? (It's hard to tell what the intent of the new package is.) I'd love to hear other suggestions. Perhaps zope.browser is the most straightforward location, especially given the names of the views involved. Even if zope.browser has unclear intent now it'll gain more clear intent from this. That said, zope.browser currently doesn't depend on zope.location and it would need to gain this as a dependency. 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. I would prefer if we could make TestRequest also go somewhere else (zope.browser?) instead of making zope.publisher a test-only requirement. While that step would be an improvement, I think the greater improvement would be to find a way to reduce test-only requirements. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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 perhaps not in an obvious place for you:
http://shane.willowrise.com/archives/repozublisher/
http://shane.willowrise.com/archives/redesign-of-zopepublisher/
http://shane.willowrise.com/archives/zopepipeline/
http://shane.willowrise.com/archives/limits-of-zopepipeline/
I've noticed that nearly all packages that depend on zope.publisher
depend only on a few pieces of it:
- zope.publisher.interfaces
- zope.publisher.browser.Browser{View|Page}
- zope.publisher.browser.TestRequest
I'd like to turn this around a little bit. Only browser-based code
should depend on zope.publisher. This seems like a very reasonable
dependency. It's like wxwindows UI code depending on wxwindows.
Maybe the browser code should be factored out of the packages that
depend on zoep.publisher so that only *that* code has the dependency
and non-browser code doesn't.
Shane, how integrated is code that relies on the pieces in
zope.publisher you identified into their own packages? I have the
impression it'll be much harder to go that way than factor bits out of
zope.publisher instead. Especially as zope.publisher contains stuff that
Shane has no use for with zope.pipeline, and we'd still be pulling it in
if we didn't do the refactoring.
We got two kinds of browser-based code we should distinguish between:
* ZMI code
* framework code that supports the browser
To get rid of ZMI code, a pattern that works fairly well is to refactor
everything *else* out of the package and leave the ZMI code in its
original location, with backwards compatibility imports in place.
zope.app.* packages frequently can get this kind of treatment.
Other framework code that supports the browser is much like any other
framework code. Some packages need to be aware of the browser in order
to perform their role as framework component at all. If those packages
can rely on *less* code that would be an improvement.
I'm not very much in favor of making these sub-packages of
zope.publisher though, as to me a sub-package structure tends to make an
implication that it relies on the outer package, which in this case it
doesn't. I'd rather see zope.browser take this role. Perhaps the current
zope.browser package doesn't have the right name?
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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.publisher just for TestRequest. I would make zope.publisher a test-only requirement. Frankly, any code using a testing stub which is that heavyweight needs to be refactored. There's nothing all that heavyweight about TestRequest. - - It derives from BrowserRequest, which means carrying along a *lot* of extra implementation baggage. Tests which use this class, rather than stubbing out a dummy request which provides only the API required by the application-under-test, will tend to grow unexpected / undesirable tentacles to the request implementation. - - 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 the context of it. Any view (or resource) code, which is the only code who's tests would need zope.publisher, will be used in together with zope.publisher in practice. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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 the context of it. Any view (or resource) code, which is the only code who's tests would need zope.publisher, will be used in together with zope.publisher in practice. Yep, I agree. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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.pipeline, that doesn't need this other code. Is that correct, Shane? I see. He only needs the interfaces, so that he can write compatible code. And he is doing some rest-like stuff, so he does not need browser. I would only factor out the browser code, if it introduces additional dependencies. 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. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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 that is meant to run in the context of it. I think it's a very subjective and relative measure. Some people call 15 packages a very big dependency. Some measure it in terms of actual features you get and think it's small. Hanno P.S. See http://hannosch.eu/dependencies/zope/zope.publisher.svg for the dependency graph ;) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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 ready. Can you elaborate on this a bit? He has, though perhaps not in an obvious place for you: http://shane.willowrise.com/archives/repozublisher/ http://shane.willowrise.com/archives/redesign-of-zopepublisher/ http://shane.willowrise.com/archives/zopepipeline/ 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. ... I'd like to turn this around a little bit. Only browser-based code should depend on zope.publisher. This seems like a very reasonable dependency. It's like wxwindows UI code depending on wxwindows. Maybe the browser code should be factored out of the packages that depend on zoep.publisher so that only *that* code has the dependency and non-browser code doesn't. Shane, how integrated is code that relies on the pieces in zope.publisher you identified into their own packages? I have the impression it'll be much harder to go that way than factor bits out of zope.publisher instead. I'd like to see see some specific examples. In general, in Zope 3, we've advocated a separation of model and application code from presentation code. Presentation code is going to depend on whatever presentation framework it uses. Especially as zope.publisher contains stuff that Shane has no use for with zope.pipeline, and we'd still be pulling it in if we didn't do the refactoring. I'm not sure why this matters. BTW, I suspect we're more concerned about odd dependencies *of* zope.publisher, like zope.location. It might be better to focus on some of those. I'd also be in favor of separating out less central parts, like support for xml-rpc. We got two kinds of browser-based code we should distinguish between: * ZMI code There shouldn't be anything in zope.publisher that depends on the ZMI. * framework code that supports the browser To get rid of ZMI code, a pattern that works fairly well is to refactor everything *else* out of the package and leave the ZMI code in its original location, with backwards compatibility imports in place. zope.app.* packages frequently can get this kind of treatment. Other framework code that supports the browser is much like any other framework code. Some packages need to be aware of the browser in order to perform their role as framework component at all. If those packages can rely on *less* code that would be an improvement. I'm not sure what you're saying. If an application package has presentation code mixed into it and if there is a desire to use that application code in a context without presentation, I'd separate the presentation code from the application code. The presentation code would depend on zope.publisher. The application code wouldn't. I'm not very much in favor of making these sub-packages of zope.publisher though, as to me a sub-package structure tends to make an implication that it relies on the outer package, which in this case it doesn't. I'd rather see zope.browser take this role. Perhaps the current zope.browser package doesn't have the right name? I don't know what you mean by these above. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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 discussing zope.pipeline on my blog. I am attempting to
rebuild the publisher to make it easier to understand and customize. I
think it's working out pretty well. zope.pipeline is intended to
replace most of the implementation code in zope.publisher and
zope.app.publication.
To accomplish that, it looks like I ought to separate the
implementations in zope.publisher from the specifications. Separating
the zope.publisher.interfaces package would mostly accomplish that.
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 for zope.pipeline, so I'm
going to withdraw from that part of the discussion for now.
I've noticed that nearly all packages that depend on zope.publisher
depend only on a few pieces of it:
- zope.publisher.interfaces
- zope.publisher.browser.Browser{View|Page}
- zope.publisher.browser.TestRequest
I'd like to turn this around a little bit. Only browser-based code
should depend on zope.publisher. This seems like a very reasonable
dependency. It's like wxwindows UI code depending on wxwindows.
Maybe the browser code should be factored out of the packages that
depend on zoep.publisher so that only *that* code has the dependency
and non-browser code doesn't.
I think things are already pretty well factored in that sense. Take
zope.formlib, for example. It wouldn't make sense to separate
zope.formlib into an abstract package and a browser package, because
zope.formlib only makes sense for browsers.
Shane
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
Hey, On Tue, Feb 24, 2009 at 6:33 PM, Stephan Richter srich...@cosmos.phy.tufts.edu 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 remove a great number of packages from the Zope Framework, so I'm not too worried about the minimization of packages right now. To properly reduce dependencies you need to go about it in an intelligent way anyway and do some actual analysis of code, so the new packages that are created tend to make sense. Fundamental goals should be: * Make the code more comprehensible * Make the code more reusable The dependency refactoring is not only an effort to make the dependencies between packages a nicer tree (and thus encourage reuse of more packages and easier understandability), but also results in trees that have less code altogether. I think the last point is very important. Less code might not be reflected directly in the amount of packages, but is a huge win anyway. Less code makes the code that remains typically far more understandable and because it pulls in less baggage also more reusable. Less code should be evaluated for the whole framework, but also for each node in the dependency tree. As an example, zope.site is a new package but contains bits of zope.app.component and zope.app.folder both. Together with the creation of zope.container and moving stuff from zope.app.component to zope.security, we can probably eventually get rid of zope.app.component altogether, along with zope.app.folder and zope.app.container. That is a net minimization of packages, and what's more important, also less code to have to understand. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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 problems with zope.publisher as you see it? Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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 to actually consider the graphs *without* such removal being done. I think doing so hides the true complexity of the dependency situation and can therefore be very misleading. At least I recall the true dependency graphs of something like zope.formlib look a lot more hairy than this: http://hannosch.eu/dependencies/zope/zope.formlib.svg I highly recommend the use graphviz's sccmap to detect clusters of strongly connected components. Circular dependencies are one of our true problems and this tool can help you identify them. It would be nice if we could have a dependency checking service that could inform us when we're going in the wrong direction; in particular when we create strongly connected clusters. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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 for zope.pipeline, so I'm going to withdraw from that part of the discussion for now. If you can make progress without doing so now, by all means. I think we do need to get back to this though eventually. It'd be bad to pull in code that actually doesn't get used when you use zope.pipeline. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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? Yep. Those are the version with transitive dependencies removed. I work on this mostly from a Plone perspective, where the full versions are just utterly unreadable. But for actual code refactoring and dependency reduction on the zope.* level the full versions are indeed more useful. I added them now. The full horror of formlib is available as http://hannosch.eu/dependencies/zope/zope.formlib-full.svg I highly recommend the use graphviz's sccmap to detect clusters of strongly connected components. Circular dependencies are one of our true problems and this tool can help you identify them. I'll check that out, thanks. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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 would be useful to try to clean that up. A while ago, I proposed a stripped down zope.publisher (zope.pub or something) that had a lot less in it, http://mail.zope.org/pipermail/zope-dev/2008-March/031170.html . I never found time to do this though. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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 allow us to more easily selectively replace or remove bits of it. +1. As I recall, we tried to build a regular architecture in zope.publisher using the IPublication interface, but the publisher machinery is still painfully difficult to understand without extensive study. I think a pipeline design will make the publisher a lot easier for everyone to understand because the pipeline design seems to keep concerns closer together. For example, I've made a traversal module in zope.pipeline which has nearly all of the traversal logic in one place and almost nothing else. Its code came from at least 4 scattered modules. Now, in theory, when people want to understand traversal, they will usually only need to understand one module. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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. Can you elaborate on this a bit? I've been discussing zope.pipeline on my blog. I just looked and I don't see many specifics. I think I have to look at the code and I don't have time for that atm. I am attempting to rebuild the publisher to make it easier to understand and customize. I think it's working out pretty well. zope.pipeline is intended to replace most of the implementation code in zope.publisher and zope.app.publication. If it is mixing those 2, them I'm not too impressed and I think those two packages have very different concerns. In any case, if what you you really want to do is to standardize some common APIs that a number of different publishing implementations can use, I'm fine with that. It should be a new package that has just those APIs and that zope.publisher could import. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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 only allow better understanding on my part, but might also allow us to more easily selectively replace or remove bits of it. +1. As I recall, we tried to build a regular architecture in zope.publisher using the IPublication interface, but the publisher machinery is still painfully difficult to understand without extensive study. 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. That isn't to say there might not be better models. Hopefully, I'll find time to study your pipeline ideas. I wish there was a proposal I could read rather than reading code. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3
On Feb 24, 2009, at 3:17 PM, Shane Hathaway wrote: Martijn Faassen wrote: One question: why is this in zope.app? I think there's a consensus we're trying to pull as much from zope.app as possible. Is this going to provide a ZMI UI at all? If not, I'd suggest putting it in zope.* I admit I'm being lazy here. It seems like zope.app is a dumping ground for packages with muddy dependencies. I didn't want to work out the dependency list yet. :-) I do have some justification though: it depends on IAuthentication, which is in zope.app.security. Still, I suspect IAuthentication needs to be moved out of zope.app.security. I agree that it shouldn't go in zope.app. I believe I suggested putting this in zc.openid, although I'm fine with zope.openid. Placement is more a function of project or originating organization, rather than dependencies. The top-level package is determined by the project/organization. Normally, there should be only 2 levels of packages. (I screwed up with the zc.recipes package, for example.) Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: Zope/trunk/ Started on a more high-level `what's new` document
Stephan Richter wrote: On Tuesday 24 February 2009, Hanno Schlichting wrote: +This version of Zope2 is compatible with and is based on Zope 3.5. Zope 3.5 has not been released. ;-) In fact development has just started. What KGS version do you guys use? This one: http://download.zope.org/zope3.5/3.5dev/versions.cfg copied locally into Zope2 SVN trunk on 2009-02-08 the last time. Plus a couple of manual updates to packages as per: http://svn.zope.org/Zope/trunk/versions-zope2.cfg?rev=96902view=markup Zope 2.11 included Zope 3.4, now its time for 3.5 (which we need for Python 2.5 / 2.6 support anyways). We are still in early alpha here. By the time we move on to beta, 3.5 will hopefully have stabilized a bit. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3
Jim Fulton wrote: I agree that it shouldn't go in zope.app. I believe I suggested putting this in zc.openid, although I'm fine with zope.openid. I'll rename it to zc.openid. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3
2009/2/24 Jim Fulton j...@zope.com: I agree that it shouldn't go in zope.app. I believe I suggested putting this in zc.openid, although I'm fine with zope.openid. Why zc? I thought it's only for packages coming from the zope corporation. Or does Shane works for ZC? :) -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3
Dan Korostelev wrote: 2009/2/24 Jim Fulton j...@zope.com: I agree that it shouldn't go in zope.app. I believe I suggested putting this in zc.openid, although I'm fine with zope.openid. Why zc? I thought it's only for packages coming from the zope corporation. Or does Shane works for ZC? :) This is for a ZC contract. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: Zope/trunk/ Started on a more high-level `what's new` document
On Tuesday 24 February 2009, Hanno Schlichting wrote: We are still in early alpha here. By the time we move on to beta, 3.5 will hopefully have stabilized a bit. What is your time frame for Zope 2.12? Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: Zope/trunk/ Started on a more high-level `what's new` document
Stephan Richter wrote: On Tuesday 24 February 2009, Hanno Schlichting wrote: We are still in early alpha here. By the time we move on to beta, 3.5 will hopefully have stabilized a bit. What is your time frame for Zope 2.12? We'll have a first alpha in the next days. Beyond that we aim for a beta release in maybe two to three months (Jim agreed on stabilizing ZODB 3.9 in about that timeframe). There's nothing definitive set here and we are open to change. If I remember correctly you wanted to aim for a shorter release cycle for Zope 3 again, by aiming for something like six month. So if we can aim to have final releases of Zope 2.12 and 3.5 during July this year, that sounds like a realistic timeframe to me. Of course this is only a suggestion (and depends on volunteer time and power as usual). Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3
2009/2/24 Shane Hathaway sh...@hathawaymix.org: Dan Korostelev wrote: 2009/2/24 Jim Fulton j...@zope.com: I agree that it shouldn't go in zope.app. I believe I suggested putting this in zc.openid, although I'm fine with zope.openid. Why zc? I thought it's only for packages coming from the zope corporation. Or does Shane works for ZC? :) This is for a ZC contract. Ah, then zc namespace if fine of course! :) -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3
Hi there, I hope in fact zope.app.* will soon become a dumping ground for deprecated packages providing legacy ZMI support. Of course that will need the consensus that the ZMI *is* legacy software. I think do we already have a consensus that packages that provide other useful functionality shouldn't be providing ZMI support within the same package. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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 something else? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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 wildly inaccurate about it? Missing transitive dependencies or something else? The graph only shows direct dependencies on zope.i18n and zope.security, but there are many other direct dependencies. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
Hey, On Tue, Feb 24, 2009 at 11:26 PM, Jim Fulton j...@zope.com 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 though it seems to remove more than just these. Hanno's now also generating the real graphs, though: http://hannosch.eu/dependencies/zope/zope.publisher-full.svg Hanno, would you consider also generating graphs for the grokcore.* packages? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope2 trunk: getting 'mkzopeinstance' / 'mkzeoinstance' working
Tres Seaver wrote: Hanno Schlichting wrote: Andreas Jung wrote: On Mon, Feb 23, 2009 at 17:46, Tres Seaver tsea...@palladion.com wrote: Creating an instance from the SVN checkout itself doesn't work for me either for the same reason. The created scripts try to use the general Python interpreter without the correct sys.path and end up missing out all the dependencies. Right: if you hack it to use the 'zopepy' script, rather than sys.executable, then the instance scripts work. I looked at this, but guessing or reliably getting to the zopepy script wasn't possible. So I added an explicit option to the script instead and documented it. You can now use: bin/mkzopeinstance --python=bin/zopepy on the SVN trunk. You can omit this option and it will use sys.executable as before. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Consensus on the ZMI and zope.app.* namespace. (Was: SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3)
2009/2/25 Martijn Faassen faas...@startifact.com: I hope in fact zope.app.* will soon become a dumping ground for deprecated packages providing legacy ZMI support. Of course that will need the consensus that the ZMI *is* legacy software. I think do we already have a consensus that packages that provide other useful functionality shouldn't be providing ZMI support within the same package. Though it's a very big +1 from me that packages providing useful functionality shouldn't contain ZMI-related stuff within the same package, and that's our goal, I wouldn't say that ZMI is a legacy software, as it's very useful out of box and can be easily extended to make real use of Zope. I'd rather say that ZMI is an example of extensible application built on top of zope frameworks and it should be positioned like that. BTW, I have a thought about an additional refactoring strategy: we could move ZMI-related packages to separate packages, like zmi.* or something, leaving imports in zope.app.* and making zope.app.* really deprecated. That way we can state that ZMI is not the Zope, but something built on it. And this way gives us more refactoring freedom :) Any thoughts? -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope2 trunk: getting 'mkzopeinstance' / 'mkzeoinstance' working
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: Tres Seaver wrote: Hanno Schlichting wrote: Andreas Jung wrote: On Mon, Feb 23, 2009 at 17:46, Tres Seaver tsea...@palladion.com wrote: Creating an instance from the SVN checkout itself doesn't work for me either for the same reason. The created scripts try to use the general Python interpreter without the correct sys.path and end up missing out all the dependencies. Right: if you hack it to use the 'zopepy' script, rather than sys.executable, then the instance scripts work. I looked at this, but guessing or reliably getting to the zopepy script wasn't possible. So I added an explicit option to the script instead and documented it. You can now use: bin/mkzopeinstance --python=bin/zopepy on the SVN trunk. You can omit this option and it will use sys.executable as before. Maybe we can detect buildout vs. tarball (e.g., the presence of 'buildout.cfg' vs. 'makefile'?) Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJpIFu+gerLs4ltQ4RAl/9AJ0fs1Re3TPN3ywPAfVO0hf18z9XzwCeNz3u Zupy2J8xlHfR7jsUTHUFe4U= =0fQW -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope2 trunk: getting 'mkzopeinstance' / 'mkzeoinstance' working
Tres Seaver wrote: Hanno Schlichting wrote: I looked at this, but guessing or reliably getting to the zopepy script wasn't possible. So I added an explicit option to the script instead and documented it. You can now use: bin/mkzopeinstance --python=bin/zopepy on the SVN trunk. You can omit this option and it will use sys.executable as before. Maybe we can detect buildout vs. tarball (e.g., the presence of 'buildout.cfg' vs. 'makefile'?) What you have available inside the mkzopeinstance script is: sys.executable which is just your regular Python interpreter and then sys.argv which is ./bin/mkzopeinstance. As the 'zopepy' script can be called anything, I don't see how you can be smarter here. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
Martijn Faassen wrote: Hey, On Tue, Feb 24, 2009 at 11:26 PM, Jim Fulton j...@zope.com 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 though it seems to remove more than just these. Hanno's now also generating the real graphs, though: http://hannosch.eu/dependencies/zope/zope.publisher-full.svg I see in that graph a number of dependencies that are pulled in just for specifications. For instance, zope.publisher doesn't really need the Location class, it only needs ILocation. Just brainstorming, but I wonder if we shouldn't split at least the following packages into specification and implementation packages: - zope.location - zope.security - zope.i18n - zope.publisher - zope.component That way various packages could use i18n interfaces without pulling in pytz, or could use location interfaces without pulling in zope.proxy, and so on. 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. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
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 zope.ilocation? Maybe. I'd lean toward zope.locationspec because it would appear right after zope.location in a sorted list, making it more apparent that they are related. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
On Wed, Feb 25, 2009 at 04:05, Shane Hathaway sh...@hathawaymix.org 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 into zope.location and zope.locationspec. what about zope.ilocation? Maybe. I'd lean toward zope.locationspec because it would appear right after zope.location in a sorted list, making it more apparent that they are related. zope.location.interfaces? -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
On Wed, Feb 25, 2009 at 12:39 PM, Lennart Regebro rege...@gmail.com wrote: On Wed, Feb 25, 2009 at 04:05, Shane Hathaway sh...@hathawaymix.org 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 into zope.location and zope.locationspec. what about zope.ilocation? Maybe. I'd lean toward zope.locationspec because it would appear right after zope.location in a sorted list, making it more apparent that they are related. zope.location.interfaces? This will not make any change in dependency graph unless zope.location become a namespace package. -- Baiju M ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
