Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Make Native Chat Handlers Overridable via Entry Points #1249
base: main
Are you sure you want to change the base?
Make Native Chat Handlers Overridable via Entry Points #1249
Changes from all commits
0141e12
86e6945
d8bec8d
c7df3a8
88db0f7
19e53af
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 it is important to avoid very long method definitions for readability. Can this block to moved to a new function inside new module, e.g.
get_chat_handler_eps()
underjupyter_ai/entry_points/utils.py
?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.
All of the validation checks should also be moved to a new function in a new module, e.g.
verify_chat_handler_class()
injupyter_ai/chat_handlers/utils.py
.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.
This doesn't seem necessary anymore because we are filtering out duplicates when getting the list of chat handler entry points (on line 457), correct?
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 that providing our own entry points to
"jupyter_ai.chat_handlers"
may not allow other extensions to override our entry points. Suppose another server extension wants to override Jupyter AI's/help
command. Then theirpyproject.toml
file contains:In the current implementation, the chat handler used for
/help
is defined by the order the entry points are loaded in, because both are setting the same key in thechat_handlers
dictionary.For example, if Jupyter AI gets loaded first, then
example_extension
overrides/help
with their custom implementation (which is desired). However, ifexample_extension
is loaded first, then the custom/help
is overridden by the Jupyter AI's default/help
(not desired).Feel free to add an example in the
packages/jupyter-ai-test
package, which is a local Python package used to verify that entry points work.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.
Great point. As per https://packaging.python.org/en/latest/specifications/entry-points/#entry-points
My understanding is that we need to loop the output of
entry_points()
(chat_handler_eps
) twice or thrice:I think we would ideally have a way to specify an entry point which will skip adding a chat handler (say to disable /
ask
if downstream has its own RAG which is not compatible withRetriver
class). This could already be done by providing one that will error out but this is of course suboptimal.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, this will be useful. Should we let extension authors add a 'disabled: true' field in the entry point classes to skip adding the entry point?
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.
@krassowski @Darshan808 Allowing other server extensions to optionally disable JAI's native slash commands seems reasonable. However, we should add contributor documentation that indicates you can disable a slash command globally by providing a mostly-empty chat handler with
disabled = True
:@krassowski BTW, we are exploring the idea of performing RAG automatically in JAI, removing the need for
/ask
. I'm going to open more issues for this to share our ideas with you & the broader public.