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

Christian Zagrodnick cz at gocept.com
Fri Jul 30 10:17:09 CEST 2010


On 2010-05-12 21:51:19 +0200, Jim Fulton said:

> On Wed, May 12, 2010 at 8:17 AM, Chris Withers <chris at simplistix.co.uk> wrote:
>> Hi All,
>> 
>> I'd like to be able to do:
>> 
>> [buildout]
>> extends=some.package:aconfig.cfg
> 
> That's an interesting idea.
> 
>> ...kinda like you can with templates in BFG, which I believe uses pkg_tools
>> to do the hard work.
>> 
>> What're the chances of that happening?
> 
> Low, in the short term. A good first step would be to work out a
> somewhat detailed proposal including:
> 
> - Descriptions of specific situations where this would solve a
>   problem, with specific examples of how the proposed meachanism would
>   be applied.
> 
> - 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 propose egg://<requirement string>/<path in egg>.

For example egg://some.package=0.6/foo/file.cfg would basically return 
pkg_resources.resource_string('some.package', 'foo/file.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 doesn't work for extends= because extends evaluated first to build 
the composed configuration. Extensions are loaded after that.

I don't see a useful way to not integrating the egg://-handler to 
buildout directly.

Are there chances this will integrated to buildout when we try that on 
a branch?

Regards,
-- 
Christian Zagrodnick · cz at gocept.com
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development




More information about the Distutils-SIG mailing list