Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.6k
[FrameworkBundle] Expose dotenv in bin/console about#24144
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
While at it patched the command to use |
if ($dotenv = self::getDotEnvVars()) { | ||
$rows = array_merge($rows, array( | ||
new TableSeparator(), | ||
array('<info>Dotenv</>'), |
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.
Dotenv
doesn't mean much unless you know what is Dotenv. Could we rename this toEnvironment variables loaded by Symfony
or something like that? Thanks.
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.
Fair point. Let me think of better name, yet i could live with "Dotenv" :) more suggestions welcome.
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.
What aboutEnvironment variables (dotenv)
?
It's enabled by usingDotenv
directly, so should be clear.
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'd useEnvironment variables (.env)
which seems more "correct". The user defined the vars in a.env
file and they don't care about how they are loaded.
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.
Managed environment variables
could do
I'm still not convinced by the naming of this option. Here we say "Environment variables (.env)" but in#23951 we say "Loaded variables". The naming must be perfectly precise: these are only the env vars loaded by Symfony from your local .env file. They are not all the env vars defined or available in your app. |
Somehow related:symfony/recipes#176 |
private static function getDotEnvVars() | ||
{ | ||
$vars = array(); | ||
foreach (explode(',', getenv('SYMFONY_DOTENV_VARS')) as $name) { |
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.
this will break whengetenv
returnsfalse
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.
@stof, explode returns an array with one empty string:
>>> explode(',', false)=> [ "", ]>>>
ro0NL commentedSep 12, 2017 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
I think it should follow with Fromsymfony/recipes#176 (comment)
Im worried for a big list of envs, cluttering the output. IMHO Same applies for web. System-wide you can check phpinfo or so (available via the profiler already). Yet we decided to list all server parameters (thus including those loaded by dotenv). Space is less an issue here. To mimic "loaded by dotenv" behavior in web, i suggest to highlight those in the current server parameters table and avoid extra panels etc.. See#23951 And technically these variables are not loaded/set by SF persee, only managed. |
ro0NL commentedSep 12, 2017 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
@fabpot@javiereguiluz i just realized.. there is I like the simplicity it brings forjust describing the feature we're implementing; expose 1) Symfony 2) Dotenv 3) Variables, a.k.a. For this PR that is 1 = We shouldnt hide this is about |
Updated. Latest version;
Works for me :) |
@@ -57,14 +71,12 @@ protected function execute(InputInterface $input, OutputInterface $output) | |||
new TableSeparator(), | |||
array('<info>Kernel</>'), | |||
new TableSeparator(), | |||
array('Type', get_class($kernel)), | |||
array('Name', $kernel->getName()), |
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.
Please, don't remove the kernel name info, it is important forName-based Virtual Kernel 4.0 applications :(
edit: I means, it is the way I can to know which app is running according to the kernel name.
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.
Agreed: please don't remove this output. Regardless, even if there was merit to the change, this seems outside the scope of this PR. We should avoid surprises that aren't directly related to the PR itself; otherwise, people will have difficulty even finding the discussion around the change.
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.
Well if we get rid ofKernel::getName()
then we're good anyway :)
Maybe i can look into that soonish;symfony/recipes#186 (comment)
In general i agree; if we keep it, it should be displayed here. Tend to remove Kernel type either way, you probably "know" this.
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.
Reverted for now :) should be discussed when deprecating getName.
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.
Let's not introduce something we know will be deprecated. If you really want to display something here, we could use the Kernel class name. That would help differentiate multi-kernel apps.
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.
We already show the kernel class name, no? Regardless, the issue isn't withintroducing something, but that this PRremoved something unrelated to the stated purpose of this PR.
IMHO, the call togetName()
here should be discussed (and possibly removed) when a PR to remove theKernel::getName()
method is introduced, not in a PR adding Dotenv output. Right?
Perhaps we should consider a special command for this as well. Tend to like But, the current proposed feature, works for me 👍 although not used in real life projects with many env e.g. |
array('Log directory', self::formatPath($kernel->getLogDir(), $kernel->getProjectDir()).' (<comment>'.self::formatFileSize($kernel->getLogDir()).'</>)'), | ||
array('Root directory', self::formatPath($container->getParameter('kernel.root_dir'), $projectDir)), | ||
array('Cache directory', self::formatPath($cacheDir = $container->getParameter('kernel.cache_dir'), $projectDir).' (<comment>'.self::formatFileSize($cacheDir).'</>)'), | ||
array('Log directory', self::formatPath($logDir = $container->getParameter('kernel.logs_dir'), $projectDir).' (<comment>'.self::formatFileSize($logDir).'</>)'), |
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 is it better to use parameters?
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.
nothing really, it's just thatgetProjectDir
is not part ofKernelInterface
, and$kernel->getContainer()->getParameter('kernel.some_path')
works for all paths / kernel instances.
See also#23624 (comment) where we favoredgetParam
over injection.
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 don't like it. I don't buy the "it is not part of KernelInterface". Using a string sounds much worse than using a method.
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.
Reverted.
Thank you@ro0NL. |
…ro0NL)This PR was merged into the 3.4 branch.Discussion----------[FrameworkBundle] Expose dotenv in bin/console about| Q | A| ------------- | ---| Branch? | 3.4| Bug fix? | no| New feature? | yes| BC breaks? | no| Deprecations? | no| Tests pass? | yes/no| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->| License | MIT| Doc PR | symfony/symfony-docs#... <!--highly recommended for new features-->For completeness in CLI, shown in web under "Server parameters".```php(new Dotenv())->populate(['APP_ENV' => 'prod', 'APP_DEBUG' => '1']);```Commits-------9011f47 [FrameworkBundle] Expose dotenv in bin/console about
Uh oh!
There was an error while loading.Please reload this page.
For completeness in CLI, shown in web under "Server parameters".