Closed colrack closed 2 years ago
Why eval
instead of source
?
I think it is more portable; I tried both .
and source
I tested on Mac OS 10.14 with sh/bash/zsh, alpine:3.10 with sh/bash and debian:9 sh/bash and with eval
was the only way to get things work out of the box.
Trying to source a file within docker run -it --rm debian:9 sh
doesn't work.
# source config/env
sh: 1: source: not found
Ah, interesting, ok.
I just didn't like that they each have to be export A=B
instead of just A=B
:)
I cannot understand what you mean (I'm not a sh ninja :) ). I tried to write a file with variables filled like
VM_COOKIE="${VM_COOKIE:-secret}"
VM_START_EPMD="${VM_START_EPMD:-false}"
and also with
VM_COOKIE=secret
VM_START_EPMD=false
but then it seems not to work for me with source env
and . env
Test case added
rebased
Can you change it to be a template? Basically have it use the same templating as if it were in an overlay with {template, ...}
.
Then it'll be closer to how Mix release works with its env.sh.eex
https://hexdocs.pm/mix/master/Mix.Tasks.Release.html#module-customization-and-configuration-summary
And to make clear it is evaluated have the name be env.sh
not env
.
Can you change it to be a template? Basically have it use the same templating as if it were in an overlay with
{template, ...}
.Then it'll be closer to how Mix release works with its
env.sh.eex
Sure, I'll be back
@colrack so the required updates are sadly more than adding .sh
to env
file name now that the 4.0 refactor has happened.
Are you still wanting to carry this forward? I can plan to handle the refactor if you aren't available. But probably after 4.0.0 is released.
add new option
env_file
where default value for env vars are specifiedexample:
where
default.env
contains default values to export, eg:will copy
default.env
toreleases/VSN/env
the extended script at runtime will read the file and set the varssee #717 see #759