[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
[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
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 FOOBAR 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 the tools are just too hard to learn under
