Martijn Faassen wrote:
It's interesting to see zope.deprecation is a new dependency. We could
consider changing these deprecations to simple imports if this is
possible...
Certainly, but what is the right way to deprecate code, then? I'm not
very happy about including zope.deprecation
Martijn Faassen wrote:
I'm not sure about zope.rest; there's already a z3c.rest which likely
does something quite different, and I think a zope.rest package should
actually *talk* about REST. What about zope.httpview instead?
Well, no, I don't think it's generic enough to call that.
Shane Hathaway wrote:
Martijn Faassen wrote:
I'm not sure about zope.rest; there's already a z3c.rest which likely
does something quite different, and I think a zope.rest package should
actually *talk* about REST. What about zope.httpview instead?
Well, no, I don't think it's generic
Shane Hathaway wrote:
Martijn Faassen wrote:
It's interesting to see zope.deprecation is a new dependency. We could
consider changing these deprecations to simple imports if this is
possible...
Certainly, but what is the right way to deprecate code, then?
We've just started to do imports
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Shane Hathaway wrote:
Martijn Faassen wrote:
It's interesting to see zope.deprecation is a new dependency. We could
consider changing these deprecations to simple imports if this is
possible...
Certainly, but what is the right way to
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Shane Hathaway wrote:
Martijn Faassen wrote:
It's interesting to see zope.deprecation is a new dependency. We could
consider changing these deprecations to simple imports if this is
possible...
Certainly, but what is the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Shane Hathaway wrote:
Ok, I've replaced all the zope.deprecation imports I added with BBB.
What does BBB stand for anyway?
Backward compatibility: we started using it as an easy-to-find marker
in code some time back.
Tres.
- --
Hey,
Shane Hathaway wrote:
Done. I look forward to seeing the changes in the dependency graph.
Great, thanks!
The only cycle left in the zope.app.publisher graph is between
zope.container and zope.filerepresentation.
The graph now contains 42 notes, so we got rid of 3 more dependencies.
Hi there,
Shane Hathaway wrote:
[snip]
Summarizing:
zope.app.publisher - zope.view
zope.app.publication - zope.publicationregistry
zope.app.http - zope.rest
I'm not sure about zope.rest; there's already a z3c.rest which likely
does something quite different, and I think a zope.rest
Martijn Faassen wrote:
So, the only dependency cycles left in zope.app.publisher are these:
zope.app.publisher -- zope.app.publication -- zope.app.http
I fixed those tonight. On the trunk, there are no longer any
dependencies between zope.app.publisher, zope.app.publication, and
Shane Hathaway wrote:
Martijn Faassen wrote:
So, the only dependency cycles left in zope.app.publisher are these:
zope.app.publisher -- zope.app.publication -- zope.app.http
I fixed those tonight. On the trunk, there are no longer any
dependencies between zope.app.publisher,
Shane Hathaway wrote:
Martijn Faassen wrote:
So, the only dependency cycles left in zope.app.publisher are these:
zope.app.publisher -- zope.app.publication -- zope.app.http
I fixed those tonight. On the trunk, there are no longer any
dependencies between zope.app.publisher,
Hey Shane,
Shane Hathaway wrote:
Shane Hathaway wrote:
Martijn Faassen wrote:
So, the only dependency cycles left in zope.app.publisher are these:
zope.app.publisher -- zope.app.publication -- zope.app.http
I fixed those tonight. On the trunk, there are no longer any
dependencies between
Martijn Faassen wrote:
Shane Hathaway wrote:
- I used zope.deferred to deprecate things I moved from
zope.app.publication, zope.app.publisher, and zope.app.http. Are there
any objections to using zope.deferred in those packages?
No objection, but what's the reason to use zope.deferred
On Sat, May 23, 2009 at 08:59:34PM +0200, Martijn Faassen wrote:
What about simply calling it zope.view? (I don't like the plural in
package names either generally)
FWIW at some point I decided that singular is appropriate when a package
defines a concept, and plural is appropriate when a
Shane Hathaway wrote:
Martijn Faassen wrote:
Shane Hathaway wrote:
In all, I changed 6 packages. Should I release them now, or should I
look for other dependencies we might clean up at the same time?
I'm +1 on releasing now. (and thanks for making them feature releases)
Getting these
Martijn Faassen wrote:
Shane Hathaway wrote:
- zope.app.publisher: A library of ZCML directives for configuring
views. Also provides generic view classes. A better name for this
package might be zope.basicviews. A lot of packages depend on this.
I'm not sure 'basic' needs to be in
Marius Gedminas wrote:
On Sat, May 23, 2009 at 08:59:34PM +0200, Martijn Faassen wrote:
What about simply calling it zope.view? (I don't like the plural in
package names either generally)
FWIW at some point I decided that singular is appropriate when a package
defines a concept, and plural
Hi there,
This is a progress report on the package dependency refactoring work.
We've had a lot of people contribute to this process (thanks
everybody!), and bit by bit we are able to make a serious impact on
dependencies. Yay!
Let's take for example zope.app.publisher, which a few weeks ago
On 5/22/09 1:11 PM, Martijn Faassen wrote:
After some work we'd gotten it down to this:
http://startifact.com/depgraphs/zope_app_publisher_cycles2.svg
And by now the main cycles left are these:
http://startifact.com/depgraphs/zope_app_publisher_cycles3.svg
So, the only dependency cycles
Chris McDonough wrote:
On 5/22/09 1:11 PM, Martijn Faassen wrote:
After some work we'd gotten it down to this:
http://startifact.com/depgraphs/zope_app_publisher_cycles2.svg
And by now the main cycles left are these:
http://startifact.com/depgraphs/zope_app_publisher_cycles3.svg
So, the
21 matches
Mail list logo
