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 had a
dependency structure like this:
http://startifact.com/depgraphs/zope.app.publisher-before.svg
(60 dependencies, including zope.app.form and zope.formlib).
After a lot of work on a lot of packages, we now have a dependency
structure like this:
http://startifact.com/depgraphs/zope.app.publisher-after.svg
(45 dependencies, no more form related stuff)
Still a big graph, but a lot simpler nonetheless, and down 15 packages.
So, due to the recent changes we've now managed to cut away
zope.app.form and zope.formlib entirely from zope.app.publisher's
dependency chain (except for the tests).
The main dependency cycles we started out with in the big graph were these:
http://startifact.com/depgraphs/zope_app_publisher_cycles.svg
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 left in zope.app.publisher are these:
zope.app.publisher <--> zope.app.publication <--> zope.app.http
And also this (familiar) one:
zope.container <--> zope.filerepresentation
I need to do some more analysis to see what other complexities we have
in the dependency chain in the ZTK.
One obvious set of tasks is to continue evaluating dependencies of
things like zope.app.publisher to see whether we cannot take out a few more.
Just study the graph and see what can be done by examining the code:
http://startifact.com/depgraphs/zope.app.publisher-after.svg
For instance, what is zope.app.pagetemplate doing depending on
zope.dublincore? What about its direct dependency on zope.container?
Another set of tasks is to examine all the test dependencies we have, as
those are way more complicated than the main dependencies. Ideally our
test dependencies shrink to nothing as well. This will be a hard slog as
we rewrite tests, but we can target one dependency at the time, too.
Regards,
Martijn
Hello,
Following just happened. The project has KGS 3.4 versions as a base,
locally I wanted to override lxml to >= 2.1.1.
[...snip...]
extends = http://download.zope.org/zope3.4/3.4.0/versions.cfg
versions = versions
[versions]
lxml >= 2.1.1
[...snip...]
The bin/buildout -vvvvv output was:
Installing 'zc.buildout', 'setuptools'.
We have the distribution that satisfies 'zc.buildout==1.1.1'.
We have the distribution that satisfies 'setuptools==0.6c9'.
[...snip...]
Configuration data:
[...snip...]
[versions]
[...snip...]
lxml = 1.3.6
lxml > = 2.1.1
[...snip...]
Getting required 'lxml==1.3.6'
We have the distribution that satisfies 'lxml==1.3.6'.
[...snip...]
I thought the local [versions] would override the inherited ones?
If I put
lxml = 2.1.1
buildout nicely picks 2.1.1
Is this a bug?
--
Best regards,
Adam GROSZER mailto:agroszer@gmail.com
--
Quote of the day:
Time is nature's way of making sure that everything doesn't happen at once.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
Please exclude the mass-email, most of you will receive this more than
once, we're hoping to catch any current contributor whose email
address on zope.org is not current. Anyone who has svn.zope.org
checkin privileges and has not received personal email with the
content below, please read and follow the instructions, otherwise you
may find yourself without access.
Thanks!
jens
- -----------------------------------------------
You may be aware that the copyright for software stored in the
software repositories on svn.zope.org has recently been assigned
to the Zope Foundation, from the earlier copyright holder Zope
Corporation. The old contributor agreements expressly assigned
a joint copyright to Zope Corporation for any software checked
into svn.zope.org repositories. With the Zope Foundation taking
over these copyrights, the agreement with the contributors needs
to change so that the Zope Foundation is the joint copyright
holder for all new code coming into the repositories.
For you as a contributor this means you need to submit a new
contributor agreement[1] if you want to stay on as an active
contributor to Zope and/or the other software hosted in the
repositories on svn.zope.org. Here's how:
- - download the new agreement[1]
- - fill in the new agreement, and since you are a current
contributor it is OK to enter Jim Fulton (jim(a)zope.com) as the
required reference committer
- - sign and date the agreement
- - either scan the agreement and email it to foundation-info(a)zope.org,
or fax it to the Zope Foundation fax number +1 (703) 842-8076
To ensure a timely copyright transition we ask you to submit the
new contributor agreement no later than June 17, 2009. The
Zope Foundation board will try to contact any contributor who
has not replied at that point between June 18 and June 26, and
on June 26 checkin access will be removed for those who have not
sent in the new agreement.
Thanks again for your support!
Jens Vagelpohl
Secretary, Zope Foundation Board of Directors
[1] http://foundation.zope.org/agreements/ZopeFoundation_Committer_Agreement
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkoZOwkACgkQRAx5nvEhZLLfxwCglA45Oyk3fIr8uUasH5O4BQc9
VIEAnA2Tdk/Yh3C5bDlnIcaCklcQd/Ci
=/wUA
-----END PGP SIGNATURE-----
Hello Adam, ––
The z3c.pt package shouldn't have difficult dependencies; it depends
on zope.i18n >= 3.5 but reasons unknown to me (Hanno CC'ed).
Note that the package no longer depends on ``lxml``.
\malthe
Hi,
So, we determined that OFS.Traversable's unrestrictedTraverse()
shouldn't grow support for IPublishTraverse, which is fair enough. We're
now using an ITraversable adapter instead (++namespace++).
However, we found another inconsistency. In URL traversal, this works:
/foo/bar/++namespace++/123
In OFS.Traversable, it doesn't, but this does:
/foo/bar/++namespace++blah/123
The reason is that in restrictedTraverse(), we have this check:
if name and name[:1] in '@+' and name != '+' and nsParse(name)[1]:
ns, nm = nsParse(name)
However, nsParse(name)[1] is '' if no name is provided after the namespace.
In BaseRequest.traverseName() we have a similar, but more relaxed check:
if name and name[:1] in '@+'
ns, nm = nsParse(name)
if ns:
...
This also has the advantage of not calling nsParse() twice.
I can't understand why OFS.Traversable would explicitly disallow
namespace traversal with an empty string as the name. Is this on
purpose, or a bug?
Cheers,
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
I just released a new version of zope.mimetype. This version no longer
depends on zope.app.component directly.
--
Alex Smith
Software Engineer
Zope Corporation
I just released a new version of zope.app.publisher. The changes in this
version are largely related to reducing dependencies on zope.app.component
and zope.app.container.
--
Alex Smith
Software Engineer
Zope Corporation
Hi there,
zope.app.publisher is depended on by quite a bit of code that uses the
Zope Toolkit, as it defines brower:view and browser:resource and the like.
Unfortunately zope.app.publisher currently depends on more than 60
packages. This is rather excessive, and we'd like to cut down on this.
Also interesting about zope.app.publisher is that while it defines a
'browser' directory it actually doesn't contain any ZMI code; instead
ZCML directives are defined there. Refactoring so the ZMI isn't around
anymore is usually a good first step, but that's not needed here.
If you look at the dependency graph for zope.app.publisher the task of
fixing this looks daunting:
http://startifact.com/depgraphs/zope.app.publisher.svg
But now please observe the following:
http://startifact.com/depgraphs/zope_app_publisher_cycles.svg
This identifies the main cycles in that dependency graph. If we break
those in the right way, we can cut down a lot of dependencies in one go.
Getting rid of the zope.app.form and zope.formlib dependencies looks
like a sensible step.
From this little graph, it looks clear we could do some of the
following things (research is needed to see how difficult they are):
* cut the dependency of zope.app.publisher on zope.app.component
* OR cut the dependency of zope.app.component on zope.formlib
* cut the dependency of zope.app.publisher on zope.app.publication
* OR cut the dependency of zope.app.component on zope.app.security
* cut the dependency of zope.app.publisher on zope.app.publication
* OR cut the dependency of zope.app.publication on zope.app.exception
* OR cut the dependency of zope.app.exception on zope.formlib
There are probably a few more options there, but given that small graph,
you get the picture.
Any volunteers to do this research on how hard some of these steps would
look and report back here? Once we've discussed the options we can
proceed fixing the problem.
Regards,
Martijn