-
Notifications
You must be signed in to change notification settings - Fork 25.7k
config: Add env_name_default and env_name_force to Config #138956
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
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/138956
Note: Links to docs will display an error until the docs builds have been completed. ✅ No FailuresAs of commit 2ed5022 with merge base 5e4c8b6 ( This comment was automatically generated by Dr. CI and updates every 15 minutes. |
This allows Configs to handle setting their defaults (or overriding themselves) via environment variables. The environment variables are resolved at install time (which is usually import time). This is done 1) to avoid any race conditions between threads etc..., but 2) to help encourage people to just go modify the configs directly, vs overriding environment variables to change pytorch behaviour. ghstack-source-id: 75c4906 Pull Request resolved: #138956
This allows Configs to handle setting their defaults (or overriding themselves) via environment variables. The environment variables are resolved at install time (which is usually import time). This is done 1) to avoid any race conditions between threads etc..., but 2) to help encourage people to just go modify the configs directly, vs overriding environment variables to change pytorch behaviour. ghstack-source-id: 6011258 Pull Request resolved: #138956
This allows Configs to handle setting their defaults (or overriding themselves) via environment variables. The environment variables are resolved at install time (which is usually import time). This is done 1) to avoid any race conditions between threads etc..., but 2) to help encourage people to just go modify the configs directly, vs overriding environment variables to change pytorch behaviour. ghstack-source-id: c0a6d9a Pull Request resolved: #138956
This allows Configs to handle setting their defaults (or overriding themselves) via environment variables. The environment variables are resolved at install time (which is usually import time). This is done 1) to avoid any race conditions between threads etc..., but 2) to help encourage people to just go modify the configs directly, vs overriding environment variables to change pytorch behaviour. ghstack-source-id: c7881c9 Pull Request resolved: #138956
| e_jk_false = Config(justknob="does_not_exist", default=False) | ||
| e_env_default = Config(env_name_default="ENV_TRUE", default=False) | ||
| e_env_default_FALSE = Config(env_name_default="ENV_FALSE", default=True) | ||
| e_env_force = Config(env_name_force="ENV_TRUE", default=False) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we not name these something longer so there is no possibility of conflict lol
|
This is probably fine but the envvar parsing is technically BC breaking |
| user_override: Any = _UNSET_SENTINEL | ||
| # The justknob to check for this config | ||
| justknob: Optional[str] = None | ||
| # environment variables are read at install time |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW, this is a problem for future us, but handling TRITON_CACHE_DIR is going to be irritating because it is NOT read at install time and we regularly change the environ to make changes. It's better for the code we write to be patching envvar, but it may be more BC to continually read out of envvar.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to approve this, but I'd feel much more comfortable if we're actually hooking this up to some config option, that will tell me if we /actually/ got the semantics right.
|
PLan is to stack a PR mograting some config options over (also need to chat with people who added the config options). |
|
@pytorchbot merge |
Merge startedYour change will be merged once all checks pass (ETA 0-4 Hours). Learn more about merging in the wiki. Questions? Feedback? Please reach out to the PyTorch DevX Team |
This never ended up getting used, and instead we're doing this resolution within the configuration system. Removing these unused internal features. Pull Request resolved: #138767 Approved by: https://github.com/ezyang ghstack dependencies: #138766, #138956
…8956) This allows Configs to handle setting their defaults (or overriding themselves) via environment variables. The environment variables are resolved at install time (which is usually import time). This is done 1) to avoid any race conditions between threads etc..., but 2) to help encourage people to just go modify the configs directly, vs overriding environment variables to change pytorch behaviour. Pull Request resolved: pytorch#138956 Approved by: https://github.com/ezyang ghstack dependencies: pytorch#138766
This never ended up getting used, and instead we're doing this resolution within the configuration system. Removing these unused internal features. Pull Request resolved: pytorch#138767 Approved by: https://github.com/ezyang ghstack dependencies: pytorch#138766, pytorch#138956
…8956) This allows Configs to handle setting their defaults (or overriding themselves) via environment variables. The environment variables are resolved at install time (which is usually import time). This is done 1) to avoid any race conditions between threads etc..., but 2) to help encourage people to just go modify the configs directly, vs overriding environment variables to change pytorch behaviour. Pull Request resolved: pytorch#138956 Approved by: https://github.com/ezyang ghstack dependencies: pytorch#138766
This never ended up getting used, and instead we're doing this resolution within the configuration system. Removing these unused internal features. Pull Request resolved: pytorch#138767 Approved by: https://github.com/ezyang ghstack dependencies: pytorch#138766, pytorch#138956
…8956) This allows Configs to handle setting their defaults (or overriding themselves) via environment variables. The environment variables are resolved at install time (which is usually import time). This is done 1) to avoid any race conditions between threads etc..., but 2) to help encourage people to just go modify the configs directly, vs overriding environment variables to change pytorch behaviour. Pull Request resolved: pytorch#138956 Approved by: https://github.com/ezyang ghstack dependencies: pytorch#138766
This never ended up getting used, and instead we're doing this resolution within the configuration system. Removing these unused internal features. Pull Request resolved: pytorch#138767 Approved by: https://github.com/ezyang ghstack dependencies: pytorch#138766, pytorch#138956
…8956) This allows Configs to handle setting their defaults (or overriding themselves) via environment variables. The environment variables are resolved at install time (which is usually import time). This is done 1) to avoid any race conditions between threads etc..., but 2) to help encourage people to just go modify the configs directly, vs overriding environment variables to change pytorch behaviour. Pull Request resolved: pytorch#138956 Approved by: https://github.com/ezyang ghstack dependencies: pytorch#138766
This never ended up getting used, and instead we're doing this resolution within the configuration system. Removing these unused internal features. Pull Request resolved: pytorch#138767 Approved by: https://github.com/ezyang ghstack dependencies: pytorch#138766, pytorch#138956
Stack from ghstack (oldest at bottom):
This allows Configs to handle setting their defaults (or overriding
themselves) via environment variables.
The environment variables are resolved at install time (which is usually
import time). This is done 1) to avoid any race conditions between
threads etc..., but 2) to help encourage people to just go modify the
configs directly, vs overriding environment variables to change
pytorch behaviour.