Skip to content

[Process] Deprecate not inheriting env vars + compat related settings #21470

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

Merged
merged 1 commit into from
Feb 1, 2017

Conversation

nicolas-grekas
Copy link
Member

Q A
Branch? master
Bug fix? no
New feature? no
BC breaks? no
Deprecations? yes
Tests pass? no
Fixed tickets -
License MIT
Doc PR -

Turning compat on/off is not a feature in itself.

About env vars: if one has unwanted env vars, one will still be able to remove them explicitly for the command. From my experience, not having eg PATH or HTTP_PROXY, etc. is more problematic. I'd prefer people to care about setting/unsetting the environment vars they know about, rather than allowing them to start with no ENV and discover later that they missed setting some var.

@fabpot
Copy link
Member

fabpot commented Feb 1, 2017

Thank you @nicolas-grekas.

@fabpot fabpot merged commit df14451 into symfony:master Feb 1, 2017
fabpot added a commit that referenced this pull request Feb 1, 2017
…elated settings (nicolas-grekas)

This PR was merged into the 3.3-dev branch.

Discussion
----------

[Process] Deprecate not inheriting env vars + compat related settings

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | yes
| Tests pass?   | no
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

Turning compat on/off is not a feature in itself.

About env vars: if one has unwanted env vars, one will still be able to remove them explicitly for the command. From my experience, not having eg PATH or HTTP_PROXY, etc. is more problematic. I'd prefer people to care about setting/unsetting the environment vars **they know about**, rather than allowing them to start with no ENV and discover later that they missed setting some var.

Commits
-------

df14451 [Process] Deprecate not inheriting env vars + compat related settings
@@ -1099,15 +1103,7 @@ public function getEnv()
*/
public function setEnv(array $env)
{
// Process can not handle env values that are arrays
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to trigger a deprecation warning when passing array values (this was added because some people were passing $_SERVER directly at some point, when inheriting was not a native feature).

@nicolas-grekas nicolas-grekas deleted the proc-deprec branch February 2, 2017 09:48
@fabpot fabpot mentioned this pull request May 1, 2017
symfony-splitter pushed a commit to symfony/process that referenced this pull request Jul 18, 2019
…es() (ogizanagi)

This PR was merged into the 4.4 branch.

Discussion
----------

[Process] Deprecate Process::inheritEnvironmentVariables()

| Q             | A
| ------------- | ---
| Branch?       | 4.4 <!-- see below -->
| Bug fix?      | no
| New feature?  | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | yes <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets | N/A   <!-- #-prefixed issue number(s), if any -->
| License       | MIT
| Doc PR        | N/A

IIUC, this method was kept as a BC layer from 3.4 to 4.0 to switch to the "inherit env vars" behavior, inciting developers to opt-in in 3.4. Since 4.0, env vars are always inherited, and this method doesn't allow to opt-out. So, time to remove it?

---

refs:

- symfony/symfony#21470
- symfony/symfony#22836

Commits
-------

af9bad31c6 [Process] Deprecate Process::inheritEnvironmentVariables()
nicolas-grekas added a commit that referenced this pull request Jul 18, 2019
…es() (ogizanagi)

This PR was merged into the 4.4 branch.

Discussion
----------

[Process] Deprecate Process::inheritEnvironmentVariables()

| Q             | A
| ------------- | ---
| Branch?       | 4.4 <!-- see below -->
| Bug fix?      | no
| New feature?  | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | yes <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets | N/A   <!-- #-prefixed issue number(s), if any -->
| License       | MIT
| Doc PR        | N/A

IIUC, this method was kept as a BC layer from 3.4 to 4.0 to switch to the "inherit env vars" behavior, inciting developers to opt-in in 3.4. Since 4.0, env vars are always inherited, and this method doesn't allow to opt-out. So, time to remove it?

---

refs:

- #21470
- #22836

Commits
-------

af9bad3 [Process] Deprecate Process::inheritEnvironmentVariables()
symfony-splitter pushed a commit to symfony/web-server-bundle that referenced this pull request Jul 18, 2019
…es() (ogizanagi)

This PR was merged into the 4.4 branch.

Discussion
----------

[Process] Deprecate Process::inheritEnvironmentVariables()

| Q             | A
| ------------- | ---
| Branch?       | 4.4 <!-- see below -->
| Bug fix?      | no
| New feature?  | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | yes <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets | N/A   <!-- #-prefixed issue number(s), if any -->
| License       | MIT
| Doc PR        | N/A

IIUC, this method was kept as a BC layer from 3.4 to 4.0 to switch to the "inherit env vars" behavior, inciting developers to opt-in in 3.4. Since 4.0, env vars are always inherited, and this method doesn't allow to opt-out. So, time to remove it?

---

refs:

- symfony/symfony#21470
- symfony/symfony#22836

Commits
-------

af9bad31c6 [Process] Deprecate Process::inheritEnvironmentVariables()
symfony-splitter pushed a commit to symfony/var-dumper that referenced this pull request Jul 18, 2019
…es() (ogizanagi)

This PR was merged into the 4.4 branch.

Discussion
----------

[Process] Deprecate Process::inheritEnvironmentVariables()

| Q             | A
| ------------- | ---
| Branch?       | 4.4 <!-- see below -->
| Bug fix?      | no
| New feature?  | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | yes <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets | N/A   <!-- #-prefixed issue number(s), if any -->
| License       | MIT
| Doc PR        | N/A

IIUC, this method was kept as a BC layer from 3.4 to 4.0 to switch to the "inherit env vars" behavior, inciting developers to opt-in in 3.4. Since 4.0, env vars are always inherited, and this method doesn't allow to opt-out. So, time to remove it?

---

refs:

- symfony/symfony#21470
- symfony/symfony#22836

Commits
-------

af9bad31c6 [Process] Deprecate Process::inheritEnvironmentVariables()
@faizanakram99
Copy link
Contributor

faizanakram99 commented Nov 11, 2019

How to override environment variables in processes ?
We can only unset existing env vars, not override them. Earlier the workaround was to not inherit them and use separate set of env vars for processes.

It is useful in multi-tenant applications where we want to run the same set of commands with different settings (env vars), due to this change now I'd have to switch back to native php functions :(

@nicolas-grekas
Copy link
Member Author

By using the$env argument that most methods provide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants