Remove hard-coding of jupyter_config_dir config_dir at the notebookapp level #882
Conversation
…p level, letting that being managed ny the ConfigManager.
|
Can we make this into 4.1? It is a bug fix from my point of view and more importantly, this allow to use custom ConfigManager, which provides an alternative until things related with the nbextensions discussion in #878 and jupyter/enhancement-proposals#7 is decided. |
|
It's a reasonable question. I'm not sure if we want to actually make that configurable, or remove the |
|
I'm fine with this fix. Should we merge that and Beta2 or RC ? Min ? |
|
I'm fine with it as well, I'd just like a bit more explanation of cases where it's reasonable for frontend config to come from a different place from the rest. |
|
Like other place from the disk ? I'm sure Continuum have deployment where config is on a db, or a separate folder network-mounted, or sync via dropbox. |
|
This is only relevant for breaking up user-config, so that part of user-config can come from JUPYTER_CONFIG_DIR, but the nbconfig subdir is broken out of the config dir. Arbitrary other data sources already works fine by specifying I'm mainly wondering what the case is where you would want to specify where |
|
OK, I (and others) have written some nbextensions and server extensions and package them with conda. Because we want to keep thing isolated inside prefix, we want to read the config from To workaround this for the moment I have written a custom ConfigManager which is able to read the "user" space but also the prefix space, so people can install our extensions and also install other extensions as well and have all of them activated beyond the place where the the config is located. In fact, I have no problem to avoid |
|
OK |
Remove hard-coding of jupyter_config_dir config_dir at the notebookapp level
|
After working on this stuff yesterday, I have doubts about doing this ... Will reply more later when I fully wake up... Sent from my iPhone
|
|
Thanks! I still believe we should continue discussing the whole thing in the other threads and the meeting, but at least this one gives people an entry point to workaround the whole thing if the resolution we come up later do not satisfy their requirements. |
though, jupyter#893 argues that we might need it and that it will be complex to reintroduce it. This use a convoluted way to : - warn that this kwarg might not be given to config managers in future version - but do not warn on default installs with default config. - warn that the keyword is ignored when people use subclasses of out config manager, and pass the keyword to super(). Thus this actually advertise that the keyword **might** be removed, by still allowing us to keep it if in the end it appears that we need it. Should help with jupyter#893 without un-fixing jupyter#882.
though, jupyter#893 argues that we might need it and that it will be complex to reintroduce it. This use a convoluted way to : - warn that this kwarg might not be given to config managers in future version - but do not warn on default installs with default config. - warn that the keyword is ignored when people use subclasses of out config manager, and pass the keyword to super(). Thus this actually advertise that the keyword **might** be removed, by still allowing us to keep it if in the end it appears that we need it. Should help with jupyter#893 without un-fixing jupyter#882.
though, jupyter#893 argues that we might need it and that it will be complex to reintroduce it. This use a convoluted way to : - warn that this kwarg might not be given to config managers in future version - but do not warn on default installs with default config. - warn that the keyword is ignored when people use subclasses of out config manager, and pass the keyword to super(). Thus this actually advertise that the keyword **might** be removed, by still allowing us to keep it if in the end it appears that we need it. Should help with jupyter#893 without un-fixing jupyter#882.
Pr jupyter#882 removed `config_dir` kwarg as it was ignored. though, jupyter#893 argues that we might need it and that it will be complex to reintroduce it. This use a convoluted way to : - warn that this kwarg might not be given to config managers in future version - but do not warn on default installs with default config. - warn that the keyword is ignored when people use subclasses of out config manager, and pass the keyword to super(). Thus this actually advertise that the keyword **might** be removed, by still allowing us to keep it if in the end it appears that we need it. Should help with jupyter#893 without un-fixing jupyter#882.
Let's the ConfigManager to deal with the default value, so we can make it truly configurable.
Pretend to fix #880