On Dec 11, 2007, at 10:21 AM, Jeff Shell wrote:
On Dec 6, 2007 8:08 AM, Benji York <[EMAIL PROTECTED]> wrote:
Jim Fulton wrote:
None of the above. What is the harm of the dependencies?
One of the options included in "none of the above" is to not use
buildout at all. Forget that the project in question uses buildout
setuptools) and integrate it into your project however you would have
before those tools existed (svn:externals, make a checkout,
That's such a disappointing answer. It's one that I've gotten a couple
of times when I've said "hey, I'm trying to move to a release based
system using distutils and setuptools and I'm floundering." And I have
made our own system. And it's.... I don't know. I'd like to spend more
time solving customer problems than figuring out how to install our
solutions to customer problems. We're in desperate need of reliable,
repeatable distributions. DESPERATE.
I think you are misunderstanding the context of Benji's answer.
In this case, someone is running into trouble because they are trying
to mix egg-based package management with subversion-based package
management. The Zope 2 tree uses subversion. It obtains many Zope 3
packages via subversion externals. The original poster is trying to
use some other Zope 3 packages via eggs and is packages via egg
dependencies that he already has via subversion. This is at best
annoying and at worst error provoking.
Using eggs with the current Zope 2 tree is an abuse of the setuptools-
based packaging system. There are two ways to fix this. The one I
suggested was to add egg-info directories to the Zope 2 tree to make
it compatible with eggs. Benji's suggestion was to use svn to get
additional zope 3 packages, rather than eggs. Both are reasonable
solutions in that they avoid the clash between the separate packaging
How did it come to be that the Python tools are so bad at this?
I dunno. I think we're making a lot of progress. This particular
example doesn't make me question the Python tools at all.
Setuptools is horrible when it comes to doing local
(instance-home-ish) installations, requiring virtualenv or whatever.
And I've had little success getting those to work. Maybe they just
break my way of thinking about how Python does and should work.
Whatever. Buildout looks like it tries to address many of those
issues, but again I find myself fighting against my natural instincts.
Where's some end user documentation?
The doc-test is difficult to read
and speaks in generics, not about day-to-day problems.
Everyone's a critic.
That I'm still frustrated by these tools all this time later is
Yes. I'm disappointed that you're frustrated. Thanks for sharing. I
find this post inspires me to want to take the day off to write better
I've gotten Buildout to work on some small components. It's great -
check out the source, run buildout, wait, wait, wait, and then have a
nice little self contained testing and development environment. But
I've never been able to get a full Zope 3 "Application" up and running
in that environment.
Lots of people have. I expect that there are a number of examples.
One example is the zc.z3monitor buildout, svn://svn.zope.org/repos/
main/zc.z3monitor/trunk. This buildouts out a working ZEO server and
a minimal Zope 3 application that uses it. Others might be able to
suggest better examples,
Zope3-users mailing list