Conversation
Load with ConfigManager so that merge happens recursively, unlike normal config values. Makes loading more consistent with frontend extensions, but is a bit icky because the same files are loaded and read twice, and one key in a traitlets-defined config file is loaded differently than all others. This does behave more like we intend and people expect for extensions, though.
and refactor mock test environment a bit ensures no system config files loaded or affected
- unused imports - call jupyter_path instead of reimplementing it
minrk
force-pushed
the
merge-server-extensions
branch
from
75df326 to
e70e7be
Compare
| # This enables merging on keys, which we want for extension enabling,. | ||
| # Regular config loading only merges at the class level, | ||
| # so each level (use > env > system) clobbers the previous. | ||
| manager = ConfigManager(read_config_path=jupyter_config_path()) |
There was a problem hiding this comment.
This will not pick up any overrides given to the NotebookApp - config_file_name, config_dir.
There was a problem hiding this comment.
Good call, and further evidence that this is possibly too fiddly to be worth doing in-place.
There was a problem hiding this comment.
Should work with config_dir and config_file_name now, good catch.
could be important for subclasses
| if self.nbserver_extensions[modulename]: | ||
|
|
||
| # Load server extensions with ConfigManager. | ||
| # This enables merging on keys, which we want for extension enabling,. |
| # Load server extensions with ConfigManager. | ||
| # This enables merging on keys, which we want for extension enabling,. | ||
| # Regular config loading only merges at the class level, | ||
| # so each level (use > env > system) clobbers the previous. |
|
Thanks Steve ! |
|
@minrk @Carreau @blink1073 This was supposed to merge nbserver_extensions for |
|
Looking down the rabbit hole it looks like it only applies to |
|
Thanks @blink1073! Was that done on purpose ? Any reason the notebook doesn't do the merge for nbserver_extensions in |
|
I'm not sure if that was a conscious decision historically or not, @minrk would be the best person to know for sure. |
|
.py config files also already have a clearer, explicit merge mechanism, so shouldn't have to get mixed up in this: c.Class.trait.update({'x': 5}) # update existing config, if any
# vs
c.Class.trait = {'x': 5} # override |
|
Thanks @minrk |
5 participants
Load with ConfigManager so that merge happens recursively, unlike normal config values.
Makes loading more consistent with frontend extensions, which is good.
It is a bit icky because the same files are loaded and read twice, and one key in a traitlets-defined config file is loaded differently than all others.
This does behave more like we intend and people expect for extensions, though.
closes #2063