Silence deprecations in global config if local config overrides them#12315
Silence deprecations in global config if local config overrides them#12315jacobtomlinson merged 4 commits intodask:mainfrom
Conversation
| update(config, d, priority="old") | ||
|
|
||
| update(config, collect(**kwargs)) | ||
| rename(deprecations, config) |
There was a problem hiding this comment.
defaults are already tested with the schema so it should not be relevant to test them again for deprecations?
Unit Test ResultsSee test report for an extended history of previous test failures. This is useful for diagnosing flaky tests. 21 files ± 0 21 suites ±0 5h 37m 6s ⏱️ + 5m 53s Results for commit 7bf5d89. ± Comparison against base commit 8a9b92f. ♻️ This comment has been updated with latest results. |
|
cc @djhoese |
|
I will merge later this week if there are no objections |
jacobtomlinson
left a comment
There was a problem hiding this comment.
Overall this looks fine.
Could you make sure this is covered in the configuration documentation? Especially the ignore-deprecated option.
Done |
Add support for corporate deployments where the root user installed an old version of Dask, with an associated
/etc/dask/dask.yaml, e.g.while the local user deployed a newer version of dask in a local environment with its own config, e.g.
~/.config/dask/dask.yamlIn this use case, suppress the warning that the legacy config contains a deprecated key, as it's been explicitly overwritten by the local config.
In case of deleted keys: keep raising ValueError when the user sets a deprecated key (with no valid replacement) with
dask.config.set, but just emit a warning if the obsolete key is in a config file. Also offer the user to override the config file, as they may be unable to directly modify the offending file due to permissions, as explained above.(At the moment of writing there aren't any deleted keys in dask or distributed; not sure about third-party packages that piggy-back on the same config system).