Skip to content
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

tox needs an option to unset environment variables to complement passenv #1387

Open
ssbarnea opened this issue Aug 2, 2019 · 6 comments
Open
Labels
feature:new something does not exist yet, but should help:wanted Issues that have been acknowledged, a solution determined and a PR might likely be accepted.

Comments

@ssbarnea
Copy link
Member

ssbarnea commented Aug 2, 2019

Currently there is no option to tell tox to passenv FOO_* with exceptions FOO_BAR and if you are unlikely enough to have to deal with a tool for which unset and set-as-empty-string has different behavior you are kinda out of options.

Instead of adding new options it could be easier if we would have magic value on setenv which unsets variables, taking precendence of use of wildcard on passwenv.

I initially asked on https://stackoverflow.com/questions/57293456/how-do-i-unset-an-environment-variable-with-python-tox but apparently there is no way to achieve that now.

@ssbarnea ssbarnea added the feature:new something does not exist yet, but should label Aug 2, 2019
@gaborbernat
Copy link
Member

Not sure I see this under core, if anything would need some time as a plugin to mature and maybe after then 🤔

@ssbarnea
Copy link
Member Author

ssbarnea commented Aug 2, 2019

@gaborbernat it is clearly related to passenv and setenv and I do not see any reasons for not being address by them. How is implemented is a detail, but it matters to allow user to blacklist.

If wildcards from passenv could accept regexes we could add a negative match.

Maybe a {omit} tag could make sense?

Or maybe you have another idea?

@gaborbernat
Copy link
Member

I would prefer it outside of core just because of seems rare and complicated enough that does not warrant complicating the interface for new users.

@gaborbernat
Copy link
Member

On reflection here for this, we'd want a disallow_pass_env that gets applied just before set_env (so post glob expansion).

@gaborbernat gaborbernat added this to the 4.1 milestone Jan 13, 2022
@ssbarnea
Copy link
Member Author

ssbarnea commented Apr 3, 2023

@gaborbernat To avoid adding a new configuration item, I was wondering if this could be implemented using a prefixed entry in passenv or setenv like !FOO or -FOO for the values that are not expected to be passed.

@gaborbernat
Copy link
Member

I'd prefer a new configuration than this conflating syntax. PR welcome.

@gaborbernat gaborbernat added the help:wanted Issues that have been acknowledged, a solution determined and a PR might likely be accepted. label Jun 16, 2023
@gaborbernat gaborbernat removed this from the P-1 milestone Jun 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature:new something does not exist yet, but should help:wanted Issues that have been acknowledged, a solution determined and a PR might likely be accepted.
Projects
None yet
Development

No branches or pull requests

2 participants