[Zope3-Users] Re: buildout and egg depedencies
Hi Jeff, In general, once you understand that recipes are just eggs, loaded with an entry point, and that options are passed around in dicts-of-dicts, I find buildout pretty easy to get to grips with. I understand that they're eggs with entry points. But that doesn't help me figure out all of the options available. It's hard to get a simple straightforward list of a Recipe's configuration options, how to format them (since the ConfigParser format is so godawful), etc. Well, of course there's no substitute for decent documentation! :-) Buildout itself is pretty well documented, IMHO - I use http://pypi.python.org/pypi/zc.buildout/1.0.0b31 and ./bin/buildout --help as references. The plone.recipe.* recipes also attempt to document their options clearly, for example http://pypi.python.org/pypi/plone.recipe.zope2instance/1.0 and then we have high level documentation in places like http://plone.org/documentation/tutorial/buildout. Of course, some of that's Zope 2 and Plone specific, but at least it's not an intractable problem. :) I've looked at zopeproject. The biggest problem is that we have large, existing applications that don't fit those molds. Starting up a totally fresh project? Relatively easy. Yes, of course - legacy's always hard. :) But just today, I was trying to get a running buildout instance thingy going for a customer who has a very small site which we haven't yet deployed. Now I'm just running into problems with finding out which things are configured (in ZCML) by default and which aren't. And the last stumbling block I hit before I gave up for the day involved `zope.filerepresentation` installing as a zipped egg, which then gets in the way of ZCML being able to load its configure.zcml file. I tried to find out if there was an 'always_unzip' option for Buildout, but it seems to only be a part of buildout's easy_install API. Unfortunately, that's a setuptools problem. Maybe zc.buildout could have that option - it'd be nice. Zipped eggs are a PITA when it comes to ZCML. :-( Btw, this means that no-one's ever used zope.filerepresentation except in develop mode, which is pretty crap. :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: buildout and egg depedencies
On Dec 12, 2007 3:07 PM, Martin Aspeli <[EMAIL PROTECTED]> wrote: > > The doc-test is difficult to read > > and speaks in generics, not about day-to-day problems. The Recipes are > > even worse, leaving one to clamor through the web to get back to the > > cheeseshop page and then face the same difficult to read doc-test kind > > of 'help'. Which I wouldn't mind reading, if I could easily read that > > help locally, like a man page or using Python's 'help()' system. > > ``buildout help zc.recipe.egg``, ``buildout help zc.recipe.cmmi``, > > whatever. > > +1 > > In general, once you understand that recipes are just eggs, loaded with > an entry point, and that options are passed around in dicts-of-dicts, I > find buildout pretty easy to get to grips with. I understand that they're eggs with entry points. But that doesn't help me figure out all of the options available. It's hard to get a simple straightforward list of a Recipe's configuration options, how to format them (since the ConfigParser format is so godawful), etc. I'd love to see something like this: http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html description -> options -> and then maybe some details and examples. But instead I'm scrolling my browser window up and down trying to pick out mentions of an option, and then squinting to see it in use in a doc-test block so I can see how it might be formatted. And often then, the documentation for that feature is broken out like. if you set the value to FOO, it does this: (40 lines of doctest code block) Set it to FOO&BAR to do foobrish things. Let's look at that:: (43 lines of doctest code block) I'm not going to read those 40 lines of code, half of which are manufactured output, because that manufactured output is not something I'm likely to ever see anyways. If that stuff wants to be further down the doc, fine. But it's just so hard to figure out at a glance. Again - I'm glad that there's documentation at all. I'm very glad doctest exists, as it at least promotes writing prosaic documentation of how a system works and how to interact. But it would be nice to see recipe pages start like this: zc.recipe.filestorage description: Specifies the location of a Data.fs as a buildout part, and generates some ZConfig data that may be used by other recipes (see zc.zope3recipes). options: path (optional) -- a path to a filestorage instance. If not provided, it will be placed in the part directory. provides: zconfig -- A ZConfig configuration file string containing a path to the specified or implied filestorage file. Used by zc.zope3recipes path -- The path to the filestorage file. examples: To have the filestorage in $BUILDOUT/parts/db/Data.fs (or wherever the parts directory is configured):: [db] recipe = zc.recipe.filestorage Addressing a specific file:: [db] recipe = zc.recipe.filestorage path = /opt/zodb-storage/my-app/app.fs Using with a zope3 instance home (using zc.zope3recipes:instance*) [instance] ... simple instance setup zope.conf = ${db:zconfig} [db] ... see also: zc.zope3recipes zc.zodbrecipes (ZEO configuration) And the mentions of other recipes could be links. How nice that would be! (Although, it is pretty easy to put 'zc.zope3recipes' or any other package name at the end of a cheeseshop url). Anyways, I know this is selfish wanting on my part. I've just been relatively surprised by some tools like Git recently where there's a bounty of help structured like the above. > > 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. > > Have you looked at zopeproject (uses buildout) grokproject (uses > buildout) or Repoze (uses virtualenv)? I've looked at zopeproject. The biggest problem is that we have large, existing applications that don't fit those molds. Starting up a totally fresh project? Relatively easy. But just today, I was trying to get a running buildout instance thingy going for a customer who has a very small site which we haven't yet deployed. Now I'm just running into problems with finding out which things are configured (in ZCML) by default and which aren't. And the last stumbling block I hit before I gave up for the day involved `zope.filerepresentation` installing as a zipped egg, which then gets in the way of ZCML being able to load its configure.zcml file. I tried to find out if there was an 'always_unzip' option for Buildout, but it seems to only be a part of buildout's easy_install API. > > There's just no time and t
[Zope3-Users] Re: buildout and egg depedencies
Hi Jeff, How did it come to be that the Python tools are so bad at this? To be fair, it's a hard problem. In Java land, you have similar problems with JARs in that they frequently have the same filename but different versions and there's no nice way that I know of to manage conflicts. Most Java projects I've worked on have had handful of ghost JARs - no-one knows where they come from, but they break something when removed and sometimes you get obscure errors like NoMethodDefFound when versions get out of sync... 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. virtualenv is reasonably easy in my experience (make sure you have the latest version), and reasonably natural (just use the binary in the env, not the global python binary). Whatever. Buildout looks like it tries to address many of those issues, but again I find myself fighting against my natural instincts. I've been happy with buildout when I've used it in anger. Where's some end user documentation? The cheeseshop page for buildout is pretty decent, and I wrote http://plone.org/documentation/tutorial/buildout. The doc-test is difficult to read and speaks in generics, not about day-to-day problems. The Recipes are even worse, leaving one to clamor through the web to get back to the cheeseshop page and then face the same difficult to read doc-test kind of 'help'. Which I wouldn't mind reading, if I could easily read that help locally, like a man page or using Python's 'help()' system. ``buildout help zc.recipe.egg``, ``buildout help zc.recipe.cmmi``, whatever. +1 In general, once you understand that recipes are just eggs, loaded with an entry point, and that options are passed around in dicts-of-dicts, I find buildout pretty easy to get to grips with. That I'm still frustrated by these tools all this time later is disappointing. And yes, it's easier to write your own. That's the Python way. Don't understand [zope, pylons, cherrypy, quixote, skunkweb]? Write your own web framework! Python does make it easy to do that because it's such a fantastic language. But I think that attitude, in turn, gives us worse tools, because everyone scratches their own itch and moves on, leaving everything incomplete. It seems almost like it's easier to write your own tool than to read whatever cryptic documentation exists for another. Completely. 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. Have you looked at zopeproject (uses buildout) grokproject (uses buildout) or Repoze (uses virtualenv)? There's just no time and the tools are just too hard to learn under the circumstances my little company is operating in right now. Buildout *seems* like it could fix some big problems that have been hitting us hard in recent weeks. But I still can't wrap my head around how. Maybe you should start a new thread and tell of your use cases and ask for examples of how to solve them? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users