On Dec 11, 2007 8:58 AM, Jim Fulton <[EMAIL PROTECTED]> 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 _______________________________________________ Zope3-users mailing list Zope3email@example.com http://mail.zope.org/mailman/listinfo/zope3-users