Permit empty environment variables as unset in setup.py
#4185
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change fixes a bug that causes
setup.py
to fail when any of its configuration environment variables are the empty string.For example, running the following:
Currently fails with the following message:
Because
os.environ.get
does not use its fallback argument when an environment variable exists, but is empty.Similarly,
key in os.environ
returnsTrue
for empty (but still set) keys.Shells usually do not distinguish between unset variables and empty variables, so setting variables to the empty string is usually seen as another way to unset them. This specifically arose as an issue for me while I was writing a Dockerfile, since those have no way to unset
ENV
andARG
directives—only to set them to the empty string (or to figure out and hardcode what the default would have resolved to for eachARG
). I figure fixing this here is more helpful than writing weird workarounds.This changes
setup.py
to treat unset and empty environment variables identically. This behaviour could potentially be changed in other files, as well, but that is not included here.Co-authored-by: Eta0 Eta0@users.noreply.github.com