http://coldfusion.com logo
Join Slack
Powered by
Did I read the commandbox-dotenv docs correctly th...
# box-products
r
Did I read the commandbox-dotenv docs correctly that it is not possible to have different .env files for different websites utilizing one commandbox server? I did notice that my .env and .env.example files are created in 
c:\users\ryan\
directory, which seems to suggest this. Is there any way to configure commandbox to utilize .env files tied to its own running web instance and not available/shared to all other running web instances? https://www.forgebox.io/view/commandbox-dotenv
t
I think you can load the file in your server json
from https://www.forgebox.io/view/commandbox-dotenv you can run
Copy code
server set dotenvFile=foo.properties
and see where it writes it you can also 
dotenv load
in a task runner
r
I would have thought, given the name, those variables are per-environment, i.e. per-box Like you’d added an environment variable at the OS level, it will be a constant across all applications accessing environment variables? If you have 5 instances of Lucee, they’s all share the same environment variables, however they were created?
b
@ryan The purpose of the example file is not to actually be loaded and used, but to be used a clean example file you can safely commit to your code repo to direct new devs in setting up the env vars they need
When you start a server and you have keys in your example file which are not present in the .env, then you'll actually get an error warning you the site probably won't work
It is possible to have a custom env file for a given server as Richard said above. In fact, that setting can be a comma-delimited list of env files to load so you can have more than one.
Now, that said, the actual JVM process is a monolith in that it • shares one single OS level process environment • shares one single JVM set of system properties So if you are using either the ModCFML support to have more than one web root of code, or just referring to multiple CF "applications" in subfolders with their own 
Application.cfc
, they are going to share the same collection of env vars and system props.
r
ok, that's what I was afraid of.
Thank you
b
If you have 5 instances of Lucee, they’s all share the same environment variables, however they were created?
@richard.herbert This depends on where you set them. All env vars in an operating system are "OS Level", BUT every executing process on the kernel has its own set of env vars which are a copy of whatever the parent env vars were when the process spawned. So take Linux for example • PID 1 - system.d owned by root. env vars set in this process apply to the entire server • your users shell process started when you logged in -- env vars set here (probably from your profile shell script) are visible to all process your user starts • server 1 - env vars here are specific to server 1 (but still include the previous bullets) • server 2 - env vars here are specific to server 2 (but still include the previous bullets) • and so on
👍 1
Windows uses different words, but works the same way. There are still • system env vars • user env vars • process env vars and they all start as a copy of the bullet(s) above them
And on a related note, CommandBox has its own system of env vars as well which are per-command execution (and can be nested to any level). The only marked difference is CommandBox does copy all the env vars from the parent, it maintains an internal call stack and performs a lookup, climbing the tree to resolve them, including a final look in the actual CLI JVM system properties and the native OS process running box (which is why I generally refer to them as "system settings" because they encompass several things. https://commandbox.ortusbooks.com/usage/system-settings#lookup-order use
Copy code
env debug
to visualize this. Or
Copy code
echo `env debug`
if yo want to see a command nested inside of a command 🙂
When you start a server (or run a native command for that matter), CommandBox "flattens" all the env vars that its tracking it its shell and adds them into the actual native process that's spawned so they are visible there.
r
b
Right, but I was replying to this comment of yours
I did notice that my .env and .env.example files are created in 
c:\users\ryan\
directory, which seems to suggest this.
The existence of those files doesn't suggest anything in relation to how many env files you can have for a server.
r
got you
b
I'm also not sure if you're thinking there's some significant to that directory. Without knowing what commands and in what order and where you ran them, it's impossible to know how or why those were created in that specific folder.
I would guess at some point in the past, you • ran 
box
which defaulted to having a current working dir of your user home • ran the 
coldbox create app
command, not realizing you were dumping a ColdBox app template into your user home But that's just a guess
There's really no reason why you'd want those files in that directory to be honest
There is a global env file you can create in your user home, but it's called 
.box.env
r
I had originally created .env and .env.example files in the web root of my local development environments, but when reading and running commands, the .env and .env.example files were showing in my user directory for some reason, not sure why, either. So, I will see if I can force dotenv to look up my env files from the web roots. If they are all shared on my local, I'm ok with that (well maybe, unless one key overwrites another), but my main concern was that "shared" meant that every instance shares the same env files from the user directory to which I found existing there.
b
Can you clarify if • you're using a single JVM instance running multuple web roots via the ModCFML integration • you're using more than one separate CommandBox server, each with a single web root
I can't really respond to your last paragraph until I can understand more about your setup
The dotenv module will already read a 
.env
out of the web root set in the `server.json`'s 
web.webroot
property. So if that's not working, then we can troubleshoot it.
But additional web roots used via the ModCFML integration are a totally different thing -- those aren't even known at server start time-- they are added dynamically directly to the server deployment after the server has started and dotenv has long-since done it's thing.
r
I'm using one commandbox and spin up separate websites with 
start <project_name>
. Each website represents a different client.
I have a different windows directory/webroot for each website
b
To be clear, you may have only a single 
box.exe
file on your hard drive, but running 
start xxx
twice starts TWO CommandBox instance/JVM instances/servers.
r
correct
using only one box.exe
b
So, does each web site have a separate web root on disk (different folder on disk)?
r
yes
b
Also, disregard everything I said above that pertains to ModCFML as it doesn't apply to you.
So, what exactly is your question/problem then?
I thought you were sharing a single JVM instance for more than one site, but that isn't the case now
CommandBox and dotenv should do what you need here
Copy code
C:/webroot/site1/
C:/webroot/site2/
C:/webroot/site3/
If each of those folders contains their own 
.env
file and you run 
server start
in each folder separately, then they are totally separate things, each with their own env vars
Is that not what you're seeing?
Again, the env file in your user home was likely the result of you accidentally running a command in that folder that created it. That file is not used for anything at all most likely. Look at the timestamp on that file and the other files around it to try and guess how it was created. But mostly, you can just ignore it, lol
r
I am learning to see if I can incorporate and utilize dotenv in my websites. ...Got you, thanks. So I just need to figure out why it is pointing to my user directory and maybe that will resolve the issue altogether.
b
What exactly is "pointed" at your user directory?
Again, I see no indication that 
~/.env
file is being used at all. Probably just created there on accident.
Are you still just trying to guess where it came from?
r
Yeah, I'm thinking the same and will remove it and try again
This is how I found out where it is pointing
ahh wait a sec
b
Ok, but why are you running that command in your user home??
r
I'm not pointing to a particular webroot
Yeah, exactly
b
Right, you need to actually have the working directory of the CommandBox shell in the corresponding web root
r
Thanks, going to remove the env files in users dir and then change to the proper webroot
thanks
b
Note, the 
~/
in your bullet train means your user home. 
~
is a linux convention, but bullet train and CommandBox use it as well
r
Yep, I noticed when I took a screen capture lol
ok, got it showing. Thanks, again! Also, what you mentioned regarding ModCFML helps as well. 🙂
👍 1
Open in Slack
PreviousNext
Powered by