David Pratt wrote:
Hi Jim. I think ${name} or ${part} would be good.
Sorry for poor example. baz in prev example could be a version or other
differentiating information to form a path name. Here's a better example
though there is many places this could be used.
extra-options = --datadir=${so
Hi Jim. I think ${name} or ${part} would be good.
Sorry for poor example. baz in prev example could be a version or other
differentiating information to form a path name. Here's a better example
though there is many places this could be used.
extra-options = --datadir=${software:prefix}/share
On Feb 14, 2008, at 5:59 PM, David Pratt wrote:
One other thing that I have not yet seen is using the part name
within the part which would be useful. Something like:
[foobar]
baz = bar
log = /some/path/${foobar:?}-${foobar:baz}.log
I don't follow the example. I can thing of perhaps simil
Hi Jim. Thank you for your reply. I use a number of separate config
files for buildouts, some with longer paths - was hoping to shorten them
up a bit to make them clearer (particularly if they originate from same
root).
One other thing that I have not yet seen is using the part name within
th
On Feb 14, 2008, at 2:58 PM, David Pratt wrote:
Hi. I have done some fairly sophisticated buildouts over the past
year but here's something I have not done with an extension before
now that I thought ought to be possible:
[buildout]
extends = ${some-part:path}/foo/bar.cfg
[some-part]
path
Hi. I have done some fairly sophisticated buildouts over the past year
but here's something I have not done with an extension before now that I
thought ought to be possible:
[buildout]
extends = ${some-part:path}/foo/bar.cfg
[some-part]
path = /some/where/on/my/filesystem
This produces an err
