[Distutils] [buildout] extending a .cfg supplied by another package

Wolfgang Schnerring ws at gocept.com
Fri May 14 09:47:50 CEST 2010


* Jim Fulton <jim at zope.com> [2010-05-12 21:51]:
> Chris Withers <chris at simplistix.co.uk> wrote:
> > I'd like to be able to do:
> > [buildout]
> > extends=some.package:aconfig.cfg
> - Descriptions of specific situations where this would solve a
>   problem, with specific examples of how the proposed meachanism would
>   be applied.

I don't know what Chris had in mind, but one use case for me is
versioning the buildout configuration and keeping it in sync with the
package I'm buildouting. For example, say the way a package is deployed
changes from its version 1.5 to 2.0, so some buildout parts need to work
differently than before, e. g. because the appserver needs to be
configured differently now.

I'm not aware of a good way to deal with that currently, other than
using an SCM tag for the buildout config files. But this is cumbersome,
as a) it's an additional thing you need to do when cutting a release and
b) you need to take care to first figure out and then check out the
matching buildout config version for the package version you want to
deploy.

If I could put the relevant buildout configuration into the egg itself,
that would handle this issue nicely.

> - A syntax proposal.  It has to address distinguishing file paths from
>   urls from these new things. I suspect these should be expressed as
>   URLs, e.g.:
>      project://some.project/aconfig.cfg

I'd propose egg://some.dotted.name/config.cfg

> I'll note that I suspect you can do this now using a buildout
> extension that installs a new URL handler in urtllib2.

That's an interesting approach. I'd definitely want to use buildout's
egg version handling/pinning for the "extends egg", but yeah, maybe
that'd be possible that way, too.

Wolfgang



More information about the Distutils-SIG mailing list