[Zope3-Users] buildout and egg depedencies

Jeff Shell eucci.group at gmail.com
Tue Dec 11 16:03:27 EST 2007


On Dec 11, 2007 8:58 AM, Jim Fulton <jim at zope.com> wrote:
> 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.

Ah, sorry. I didn't realize this was the situation. But it does sound
similar to the problem that affects us. We're using a mix of CVS and
Subversion based package management. I want to get away from this, as
it's turning into a configuration-management nightmare. And even
though our internally made tools help automate checking out
known-good-revisions or branches, deployments can still be much more
painful than they should be. So, I want to change! It's just been
hard. And a lot of that is due to time constraints on my part. I never
have enough time to get to that break-through 'ah-ha!' moment.

And I'm still struggling with Eggs and .egg-info directories and all
of the path-monkeying involved and how it all works. I understand why
they have to be there, but it goes against my intuition of just
putting modules and packages into a single directory that's on
PYTHONPATH and needs no other magic. And in high pressure situations,
we keep reverting back to checkouts.


> > ...
> > 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?
>
> http://pypi.python.org/pypi/zc.buildout
> http://us.pycon.org/common/talkdata/PyCon2007/116/buildout.pdf

I forgot about that second one. I think I've scanned through it
before. I'll keep it close by as I try to sneak a buildout based app
through the system later this week. I hope.

> > The doc-test is difficult to read
> > and speaks in generics, not about day-to-day problems.
>
> Everyone's a critic.

I greatly, greatly appreciate the fact that there is documentation and
that it is a test and therefor up-to-date.

But it's just not good introductory nor quick reference documentation.
It's an extremely intimidating document, with the good information
(command line options, default buildout config options with a brief
summary of each) being buried way down in the document - after a lot
of things about writing Recipes (most of which seem in place as a way
of providing means to show what buildout is doing within the confines
of a doctest). Every time I use buildout, I scroll up and down that
document trying to find what I need. And then there are the inline
examples with the '%s' placeholders: awesome for testing and not bad
for reading. But not great for reading, either. It adds extra line
noise that I have to filter out.

Under the constraints of what can be done within a doc test, I think
you guys have performed miracles. And it's much much better than no
documentation at all. But it's a lot of information, all presented
within a single page that seems to be the de-facto homepage for the
tool and the sole source of documentation (and the recipe links are
busted). If the tool is maturing, it may be time to give buildout a
bone-simple site, maybe all generated from Restructured Text, which
could house the big-gigantic-doctest-readme and could start to house a
manual written along the same lines (perhaps extracted from the big
doctest readme) along with tutorials. I can understand waiting on
doing that until the tool matures, but it seems to be doing alright
(2-3 months between recent beta releases).

> > 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.

For what it's worth, I've gotten full third party apps (z3c.formdemo)
running, and I think I got a zopeproject based thing running; but I
haven't been able to get our existing applications to that point. None
of them are in distutils friendly format, let alone buildout friendly.
That's the part I struggle with. Part of the struggle is due to us
still being on CVS, but we'll be moving to Git soon, and I'll finally
be able to restructure our libraries without the hacks I currently
have in place.

I think the information that would be most beneficial is good
practices when it comes to declaring dependencies. In setup.py? In
buildout.cfg? Repeated in both? Our big old libraries (which I also
hope to break into smaller components as we change source code
management systems) use a LOT of Zope 3. Do I grep the source for
'from zope ...' and 'import zope.*' and list all unique dependencies
that I find?

> 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,

Thanks,
Jeff Shell


More information about the Zope3-users mailing list