* Jim Fulton <[email protected]> [2010-05-12 21:51]: > Chris Withers <[email protected]> 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 _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
