Closed thedrow closed 11 years ago
Ok, just to make sure I understand correctly, here a small example of the feature you would like.
Let's say we have the following configuration:
db:
user: "root"
password: "value"
This should results in ENV["db.user"] = "root"
and ENV["db.password"] = "value"
being set in the guest VM launched from the Vagrantfile
? And they should be unset on vagrant halt/reload/destroy
.
Is this correct?
If yes, this leads me to the naming of the environment variable names.
I prefer choice 2
, but choice 3
is an exact mapping from the Vagrantfile
. Choice 1
could lead to unexpected collisions but is the more straightforward. What is your preference?
Regards, Matt
No, that's a whole another feature although useful. I'm talking about setting those on the host - the machine that runs the VM. If I want to connect to the database I don't really need to know what's the IP of the machine, I just need to know that the DATABASE_IP environment variable is set on my machine.
You probably want to aim at option 1 but explicitly throwing an error when attempting to set an already existing environment variable.
This will not be feasible because when I will try to set the ENV
from the code, it will change the environment variables for the current child process (i.e. vagrant up
) and the changes will be lost afterward. However, the parent process (usually the terminal like bash
) will not have its variables updated, and it's not feasible directly. That's why you need to source a bash script (i.e. using source
command or adding a .
in front of your command) to have it updates the environment variables of the terminal. This is not available directly to child commands.
There is some hacks to change the global environment variables at the system level but it's not working on every system and it's sometimes unreliable. But there would still be a problem for the terminal from which the command was launch because it would not have the new values until a restart.
I fear I will be unable to implement such feature.
Maybe you can generate a bash file the users will source?
Indeed, that would be easily doable. In fact, we could even make this easier by outputting the right commands directly from a vagrant command and you could source that.
. vagrant user env
This would output the various export commands needed to create environment variables. I could then add a flag to unset them vagrant user env --unset
.
It will test this possibility friday morning.
Thank you very much!
I just released 1.3.0
which include the necessary command and options to generate the export (and unset) commands.
Check Env command section for information on the feature specially method #1 (creating a small delegate script) and method #2 (use command to create script then source it).
Don't hesitate to re-open if something is not clear or not working as expected.
Awesome. Can I suggest using https://github.com/kennethreitz/autoenv or https://github.com/bkeepers/dotenv or similar instead of creating a bash script as a third method?
Yes, that sounds good, did not know about those tools, very nice. Do you know/use those tools, because from a quick lookout, they seems to have different syntax for the .env
file, autoenv
seems to use command directly (which is exactly like current commands output), where the other seems to be plain variable (i.e. name=value
, no export
).
I haven't tried using any of them but I was planning to after this feature was complete. You can possibly add a --format argument that emits other formats.
I have just released 1.4.0
with support for autoenv
export file. I also changed the export architecture to simply adding new export format.
Using vagrant user env --format autoenv
will create a .env
file in the current directory where the command was executed. You will then be able to just cd
into the directory to have environment variables available.
If you need support for https://github.com/bkeepers/dotenv, don't hesite to open another issue.
Wonderful, thanks!
This is useful for databases where you can export the configured username and password, database name and more for example. Those environment variables should be unset when you vagrant halt/reload/destroy.