-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Cascading Schemas #10010
Cascading Schemas #10010
Comments
You can still override schema defaults as a system administrator with the overrides.json file. See https://jupyterlab.readthedocs.io/en/stable/user/directories.html?highlight=overrides.json#overrides-json |
Hi @jasongrout, This worked pretty well, but I ran into three issues:
|
This is #9858 (for 3.1)
Right, we don't merge keys. Perhaps we should? That comes with its own set of problems to make sure things are consistent, etc. |
What if we did something a bit hacky?
|
Great question, thanks for asking. I haven't thought a lot about it, so I'm not sure how I feel about it (and of course would love others to chime in as well about what they think). Is this something you'd want to open a PR for? |
Depends on how complex it would be - any pointers? Also, where is |
The code is in https://github.com/jupyterlab/jupyterlab_server/blob/master/jupyterlab_server/settings_handler.py (search for "overrides" to see places where the logic is implemented). |
Here is where the overrides.json file is actually read in: https://github.com/jupyterlab/jupyterlab_server/blob/34ce153057af9ffdaca8a97203dd554d3c395758/jupyterlab_server/settings_handler.py#L258-L273 |
We can open a PR for this. Any objections to the magic private key proposal above (i.e. |
@blink1073 this issue is still open as we discuss what to do about |
👍🏼 |
Thoughts on this @blink1073 ? |
Problem
Jupyter's config (and data) use a cascading model for loading configs. An admin can set a systemwide default config in the venv which overrides the Jupyter defaults; then a user can set another config to override those. This model works very well for deploying Jupyter in a shared environment. Schemas don't share this cascading model, making it hard to override defaults as an administrator. In jupyter@2.0, an admin could override the generated schema directory, but with federated modules, that does not seem possible.
Proposed Solution
Add a third directory for schemas that is configurable. This would be merged with federated/installed modules default schema to become the "System Defaults" that a user sees. "User preferences" overriding these would remain unchanged.
Note: I am unfamiliar with this code, so there may be a much simpler way.
The text was updated successfully, but these errors were encountered: