<p dir="auto">The ParameterBag class is implemented in two components and has different interfaces.</p>
<p dir="auto"><code class="notranslate">Symfony\Component\HttpFoundation\ParameterBag</code><br>
<code class="notranslate">Symfony\Component\DependencyInjection\ParameterBag</code></p>
<p dir="auto">I can understand the duplication to avoid inter-module dependencies, but i do not understand why the different interfaces. For example the Http version allows default values:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="$bag-&gt;get('name', null)"><pre class="notranslate"><code class="notranslate">$bag-&gt;get('name', null)
</code></pre></div>
<p dir="auto">Where the DI version does not and makes you do:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="$bag-&gt;has('name') ? $bag-&gt;get('name') : null"><pre class="notranslate"><code class="notranslate">$bag-&gt;has('name') ? $bag-&gt;get('name') : null
</code></pre></div>
<p dir="auto">Could these be united? at least the interfaces? or is it a issue with requirements?</p>
<p dir="auto">Hello,</p>
<p dir="auto">After a discussion on Symfony Slack about environment variables and CLI around my question:</p>
<blockquote>
<p dir="auto">I’m interested into how the community solves the <em>environnement variable and the CLI</em>.</p>
</blockquote>
<p dir="auto">It seems that nothing solid came out out of this discussion.</p>
<p dir="auto">The documentation states that environment variables <a href="https://symfony.com/doc/current/configuration/external_parameters.html#environment-variables" rel="nofollow">should be added on the webserver level on production</a>.</p>
<p dir="auto">Nothing is said reguarding the <code class="notranslate">CLI</code>, so a lot of people (like me) will end up spending time looking for why a crontab entries is not executed.</p>
<p dir="auto">To me, prefixing the executed commands by the environment variables is <em>not a good solution</em>. I mean, it would involve:</p>
<ul dir="auto">
<li><em>variable duplication</em> (so bad maintenance, "oops forgot to add this variable in this place"),</li>
<li>and very <em>bad lisibility</em> (prefix with 20+ environment variables <g-emoji class="g-emoji" alias="thinking" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/1f914.png">🤔</g-emoji>?)</li>
</ul>
<p dir="auto">Regarding of this, why push in favor of environement variable if the only way of achieving this is to use a <em>not recommended way</em> (<code class="notranslate">.env</code> file).</p>
<p dir="auto">One alternate solution would be to create a file on the system in <code class="notranslate">/etc/environment</code> that contains those environment variable, BUT again, <em>what happens if your server hosts multiple projects</em> and you want one app X to be <code class="notranslate">APP_ENV=prod</code> and the other Y <code class="notranslate">APP_ENV=dev</code>, then you have a variable collusion with the name unless you change the <code class="notranslate">APP_ENV</code> variable name in all project to include a vendor prefix ? (I don't even know if it's feasible).</p>
<p dir="auto">Not all of us use containers to run in production (or doesn't even want to).</p>
<p dir="auto">PS: I open this here instead of the documentation repository because it reveals more questions than just "how to deal with that in doc is missing".</p>