fix: respect false-like env flags#366
Closed
Bojun-Vvibe wants to merge 1 commit intosamuelcolvin:mainfrom
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Repo: samuelcolvin/watchfiles (⭐ 2000)
Type: bugfix
Files changed: 3
Lines: +46/-5
What
This change makes
WATCHFILES_DEBUGandWATCHFILES_IGNORE_PERMISSION_DENIEDtreat explicit false-like values consistently. Instead of enabling those flags for any non-empty string,false,disable, anddisablednow correctly resolve toFalse, and the new tests cover those cases alongside the existing truthy and unset behavior.Why
Before this patch, setting
WATCHFILES_DEBUG=falseorWATCHFILES_IGNORE_PERMISSION_DENIED=falsestill enabled the option because Python treated any non-empty environment variable as truthy. That is surprising for users trying to disable those flags in shell or container environments, and it was inconsistent withWATCHFILES_FORCE_POLLING, which already recognized false-like strings.Testing
Committed focused test coverage for the new env-var cases in
tests/test_force_polling.pyandtests/test_rust_notify.py. A direct Python sanity check confirmed the changed helper behavior for unset, empty,1,false,disable, anddisabledvalues. Targeted pytest execution was attempted, but the host environment injects external pytest plugins that fail before repo tests run.Risk
Low / narrow change to env-var parsing for two boolean helpers, with matching regression coverage added.