New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#473 Add feature to load server environment variables from special file #474
#473 Add feature to load server environment variables from special file #474
Conversation
Hi @adamwathan @mattstauffer, is there any reason for not merge this pull request? I found that I need to set Thank you EDIT: I'm talking about not-laravel projects |
@Lloople I don't see anything particularly wrong with the PR. What I did was close obvious "no" PRs, shut down all driver requests for now, and leave PR's like these open for Adam and Taylor to merge when they have some time to look over them and decide whether they fit within the spirit/intent of Valet. I think this being open is not a "no" but just a "taylor and adam haven't had time to dig into it yet". |
Please add this implementing |
Hi, I think is a good approach for some kind of projects to have env variables and load it inside a project. Totally agree to merge it @mattstauffer |
Nice work! Would love to see this one get merged. |
Notwithstanding the merge conflict here (which I think is a simple fix), and that this PR touches most drivers, I like this. One concern: naming the file |
cli/drivers/BasicValetDriver.php
Outdated
@@ -44,10 +44,12 @@ public function isStaticFile($sitePath, $siteName, $uri) | |||
*/ | |||
public function frontControllerPath($sitePath, $siteName, $uri) | |||
{ | |||
$this->loadServerEnvironmentVariables($sitePath, $siteName); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this seems to be happening in every frontControllerPath
method, is it possible to instead just run this in server.php
right before it calls frontControllerPath
? (I don't know the code super well so there may be a good reason why not...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically it probably could.
Lines 134 to 147 in 0323607
/** | |
* Attempt to dispatch to a front controller. | |
*/ | |
$frontControllerPath = $valetDriver->frontControllerPath( | |
$valetSitePath, $siteName, $uri | |
); | |
if (! $frontControllerPath) { | |
show_valet_404(); | |
} | |
chdir(dirname($frontControllerPath)); | |
require $frontControllerPath; |
fea72f9
to
a603114
Compare
@mattstauffer @drbyte I took both your advices and refactored this idea. Let me know what you think! If this gets merged into master, I would also love to help with the documentation of this feature, how can I do that? |
} | ||
|
||
foreach ($variables[$siteName] as $key => $value) { | ||
$_SERVER[$key] = $value; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not using putenv($key.'='.$value)
here along with the already existing $_SERVER
? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was only trying to mimic Apache's way of loading env vars on the vhosts files, and if I'm not mistaken, that only sets values on$_SERVER
.
I don't know if duplicating the values on both $_SERVER
and $_ENV
is useful or desirable, but as you say, we can add that single line to the loop if we do.
What say the rest of us?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no objection.
@MartinPeverelli have you considered a way to allow for wildcard domain-names with this? I have a use-case where simply dropping in a non-domain-specific |
I've used this proposed PR on a project. It worked well. I do think altering it to allow for being domain-agnostic would be nice too. |
- added `putenv()` for Laravel compatibility - added `$_ENV` for generic compatibility - added wildcard processing, so site array named `*` gets processed always (if present), and then site-specific entries are added and will override the wildcard. Sample `.valet-env.php`: ```php <?php return [ '*' => [ 'USER' => 'vagrant', ], 'demo' => [ 'MY_CUSTOM_VAR' => 'special_value', 'USER' => 'travis', ], ]; ``` (Note: order of entries in the array is irrelevant, as the parser reads `*` first, followed by site-specific entries.)
Waiting for @MartinPeverelli to merge my PR to his valet fork, which will update this PR, and then this could be merged. |
Updated loading of server environment variables
@drbyte merged your PR into my fork! Sorry for the delay, hectic RL. |
Thanks @MartinPeverelli I've been using this code for the past 3 weeks, and haven't run into any problems. It's definitely been helpful to keep project-specific environment variable configs in a separate @mattstauffer IMO this is safe to merge. |
Should we possibly add a PR to the docs while we're at it? |
I think I got mixed up and thought this was adding |
The change to the file name was because the contents are a PHP array, instead of the key=value pair on the other .env files. |
@MartinPeverelli sure... and you had to do PHP so you can differentiate them per domain. I remember now. Thanks! |
Note: The filename is |
Proposal for #473
Closes #473
Closes #146