-
Notifications
You must be signed in to change notification settings - Fork 307
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
Register pre/post save hooks, call them sequentially #696
Conversation
Codecov Report
@@ Coverage Diff @@
## main #696 +/- ##
==========================================
- Coverage 70.95% 70.76% -0.20%
==========================================
Files 62 62
Lines 7515 7555 +40
Branches 1190 1199 +9
==========================================
+ Hits 5332 5346 +14
- Misses 1826 1851 +25
- Partials 357 358 +1
Continue to review full report at Codecov.
|
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.
dont have much context on the functionality.. added some minor comments.
f78c480
to
5f0f6d2
Compare
Should we go ahead and merge it? This will allow to move forward with jupyterlab/jupyterlab#11599. |
I just saw the comments in the team compass:
I'm not sure, as this would allow e.g. a server extension to remove the hooks added by another extension?
It will probably be impossible to enforce a particular order. If e.g. multiple server extensions register hooks, then it is going to be the order in which the extensions are loaded.
Maybe it should also be possible e.g. or different server extensions to register the same hook?
I thinks this could be part of another PR, as it seems to require more discussion and specification. |
I'm not sure if we are talking about the same thing. I think the original meaning here was "the same function should not be called twice by the same event". Two different server extensions can install a hook, but if they both register the same function, then the hook should only be called once. For example by making the collection of hooks a set.
If this is true, then maybe the RTC handler's use of this hook needs to be rethought? AFAICT, order will be very significant for that to function as expected. |
But if the RTC handler won't be able to use this hook, then will any server extension? How can we enforce hook calling order? |
I think it is urgent to move on with jupyterlab/jupyterlab#11599, after what was reported in jupyterlab/jupyterlab#12154, since it will likely solve the issue, but this PR is blocking. I suggest that either:
I am not aware of anyone using the file hooks (did some GitHub search, but I agree it's not enough), so I would be in favor of merging this PR. |
What is Here's an problem I see using an example: If anyone has configured a post_save_hook, which likely lives in a deployment's custom config file (and likely not shared on Github if it's a company), they will expect the value of |
Which is not different from the current situation: an extension configures a |
I think this PR only improves on the current situation, and I'm planning to merge it soon if there is no feedback. |
Yes, but this is a bug. That's my point. We shouldn't perpetuate this issue by capitalizing on it here. This trait wasn't intended to be owned by extensions. As a user—you would expect that your custom configuration supersedes any config set by an extension. In jupyter_server land, where extensions are more prevalent (i.e. everything is an extension), traits like this become an issue. I think we need to fix/deprecate/etc this trait rather than exploit it here. I would suggest we create a new trait for JupyterLab to use that's a List and deprecate the old. We can iterate on the new trait (e.g. enforcing order, removing duplicates, etc.) to make it more robust over time. |
Now I'm confused, what is the audience that this feature targets? It seems to me that it's not usable by anybody, and that it should even be removed from the documentation. In my case, it would have saved me a lot of time. EDIT: sorry for ranting here 😄 |
I can create a new trait that is a |
Sorry for the confusion... "user" is a misleading term to use here. The intended us is: a person who runs Jupyter Server or JupyterLab can write a custom function and pass it to the contents manager through the config system using the # jupyter_server_config.py file
c.FileContentsManager.pre_save_hook = my_custom_function That's what the documentation is (attempting) to communicate 😅. I think a good rule of thumb is, configurable traits (i.e. traits with If JupyterLab overrides this trait after the user config is loaded, If we change this trait to be a List and allow multiple sources, including extensions, to provide hooks to that list—that seems okay to me. We probably want to add some extra logic to this List trait to address the issues that the comments above mention. |
Then, let's not make this a configurable trait? Let's add a new API to contents managers to register hooks through the API instead of the config system? |
I think we're just debating the "trait-ness" or "configurability" of this API. 😆 Let's just add a new, separate API for registering hooks from extensions? It doesn't have to collide with or go through this trait? |
Yes you're right, a new "non-trait" API sounds good 👍 |
98ca951
to
adfe0d0
Compare
Not sure what's happening in the CI:
|
I think this is related to jupyter/jupyter_client#751 |
18147cf
to
c474a89
Compare
@@ -18,7 +18,7 @@ def save(self, model, path=""): | |||
if chunk is not None: | |||
path = path.strip("/") | |||
|
|||
self.run_pre_save_hook(model=model, path=path) | |||
self.run_pre_save_hooks(model=model, path=path) |
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.
In looking at the history of this issue, including jupyterlab/jupyterlab#11599, it led me to PR #643, where this call was within the chunk == 1
block. As a result, that PR winds up calling the pre-save hook on every chunk, although the post-save hook is (still) only called on the last chunk.
I suspect a bug was introduced there but wanted to bring it up here.
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.
Indeed, thanks for pointing that out Kevin. I think it's just a matter of adding the if chunk == 1
back, right? I can open a new PR for that.
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.
Yes, I agree.
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 think this particular hook needs to still be constrained to chunk 1 even though chunks don't appear to be in use (and handled in the else
block).
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.
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.
Wouldn't the sequence be the other way around? #716 is fixing a bug in the existing (pre-this-PR) code base, then this PR is moving to a multi-valued hook trait. As it stands right now, this PR has a bug - it calls the pre-save hooks on every chunk (when chunking is used). I'd rather see the issue fixed as part of merging #716 and the merge that would need to happen to update this PR be applied, thereby correcting the chunking/pre-save-hooks bug. I thought the end game was to have the multi-valued hooks in place, merging this PR prior to #716 will re-introduce the single-hook trait.
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 fine with merging #716 first 👍
5355683
to
d0b0813
Compare
I added a test for |
Actually this should be the response to the request, I'll try to add a test for post-hooks then. |
I think this is ready to be merged, if someone could hit the button 😄 |
Great work here @davidbrochart! I'm happy to merge this. We picked up some merge conflicts here after merging #716—do you mind rebasing here? I don't think we can release until #717 is merged, because we learned from #713 that #165 introduced some backwards incompatible changes. I propose that we wait until after the weekend to cut a new release with these additions, since releasing before/over a weekend can be dangerous 😅 |
Sounds good @Zsailer, I'll rebase and we'll release next week hopefully! |
…d hook override warnings
b1ecd2e
to
8bef774
Compare
I just rebased, I think the CI failures are unrelated. |
Kicking CI to pick up fixes |
Once this passes, I'll merge and make a minor release |
Actually, I kicked #724 as well. Assuming both pass we'll get them both in |
Ditto with #717 |
Also #725 |
@davidbrochart Do you want to do a follow up to update the documentation on this? https://jupyter-server.readthedocs.io/en/latest/developers/savehooks.html?highlight=pre_save_hook The change would be to this file: https://github.com/jupyter-server/jupyter_server/blob/main/docs/source/developers/savehooks.rst |
Will do 👍 |
Closes #695