support paths relative to the user's home directory (~/foo)

[Marius Gedminas]

I'd like to specify the download cache relative to my home directory. The traditional Unix way is

[buildout]
download-cache = ~/tmp/buildout-download-cache

however zc.buildout currently doesn't interpret '~'.

[Barry Warsaw (barry)]

I wonder if a more general solution wouldn't be to expand environment variables in buildout.cfg files. Then you'd be able to say

[buildout]
download-cache = $HOME/tmp/buildout-download-cache

I think I'd like that better than ~ expansion, but honestly I don't have an immediate use case other than $HOME.

[Jim Fulton (jim-zope)]

On Jan 8, 2009, at 4:10 PM, Barry Warsaw wrote:

> I wonder if a more general solution wouldn't be to expand environment
> variables in buildout.cfg files. Then you'd be able to say
>
> [buildout]
> download-cache = $HOME/tmp/buildout-download-cache
>
> I think I'd like that better than ~ expansion, but honestly I don't
> have
> an immediate use case other than $HOME.

I'm not sure if I'd like it better or not. If we did something like
this though, I think I'd want to spell it a little differently.
I'm thinking that there might be some sort os pseudo section, say
ENVIRONMENT, so you could do:

    ${ENVIRONMENT:HOME}

You could even specify an ENVIRONMENT section in a buildout file to
provide a default. But the main reason I'd prefer something like this
is to not introduce a new variable-substitution syntax.

Jim

--
Jim Fulton
Zope Corporation

[Marius Gedminas (mgedmin)]

$HOME would be fine for me too, as well as variations such as ${HOME}, or even ${env:HOME}, if consistency with the existing variable substitution schemes is desired.

[Alex Clark (aclark)]

+1000 for ${ENVIRONMENT:*} in buildout, if I could do ${ENVIRONMENT:USER} that would be very useful. For example, I'd like to be able to set effective-user = ${ENVIRONMENT:USER} when running supervisor as root (which would allow some root, some non-root processes to be controlled by supervisor). But also, having the environment available in buildout would make people more comfortable using it, IMO.

[Philipp von Weitershausen (philikon)]

Seems like http://pypi.python.org/pypi/gocept.recipe.env already does
the job.

[Encolpe Degoute (encolpe)]

It tries to do the job.
As there is no escape character in buildout substitution it fails to be rebuild when an environment variable contains ${}.

[Marius Gedminas (mgedmin)]

Is it safe to use a 3rd party recipe from ~/.buildout/default.cfg? Even if it is, it's not convenient.

My primary motivation for this request was to make it easier to teach people unfamiliar with buildout how to make it faster: "create a file named this with this content". Currently the content is two lines (good) but must vary per-user (bad).

[Florian Friesdorf (flo-chaoflow)]

in #557769 i posted patched that enable:

${env:variable}, the variable itself may contain references to further sections:options

it can also be used for extends, but without further references in that case

[Florian Friesdorf (flo-chaoflow)]

full link: https://bugs.launchpad.net/zc.buildout/+bug/557769

I am happy to adjust to ${ENVIRONMENT:...}

[Marc Abramowitz (msabramo)]

${env:..} or ${environment:...} would be really nice so that I could share my ~/.buildout/default.cfg file between systems.

[Encolpe Degoute (encolpe)]

I made it in a branch that was never merged. Shame on me.
I will try to update it and produce needed usecases and tests.