-
Notifications
You must be signed in to change notification settings - Fork 62
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
Rename duplicate entrypoints #138
Rename duplicate entrypoints #138
Conversation
Hm, this seems like it would lead to more confusion around the entry-points. What if Then, |
The potential issue with notebook_shim installing the entrypoints is that the decision will be taken based on the current env situation. Then the env can evolve, e.g. you could install notebook<7, and a few days after install nbclassic. My understanding is that the entrypoints are installed once, and stay there until removed. They are not meant to be changed at runtime. |
Nevermind... I just remembered that nbclassic doesn't depend on notebook anymore. Sorry for the noise. |
No noise at all here, the picture is not easy to have in mind. Indeed, we need such entrypoints for extensions, bundlers... as nbclassic can be installed without notebook. |
@Zsailer We have discussed this at the last notebook community call, and have not found other alternatives so far. Any other thoughts/questions you would have? |
Thanks, @echarles. I'm still concerned with the degradation in the user experience here. We have already experienced a lot of confusion
vs.
Now we are looking at adding another one
I'm worried about the extra confusion that this will create. I think we should optimize for user experience here. Thinking about this more, I think I came up with a solution. Granted, it means we have to maintain one more (lightweight) package, but I believe it provides the expected user experience. I've created a new repo: jupyter_notebook_entrypoint. This repo would own the entrypoints, eliminate all conflicts, and resolve the entrypoints based on what packages the user has installed. To get this working, Notebook v6, Notebook v7, and nbclassic would all need to remove their console script definitions for these entrypoints and depend on this package. Try it out and let me know what you think! |
Simple and elegant @Zsailer. I have tested and it works great. Looking at your code, I see the following logic, which can be fine tuned (v7 first, but then not sure about nbclassic of v6).
I am also working on the endpoints aspect where we need to register under /tree the notebook v7 by priority. I don't think this is related to this discussion, but likes to highlight it also as we will have multiple places where we detect the presence of absence of packages, eg. nbclassic/nbclassic/__init__.py Lines 10 to 15 in 33f5cbd
|
@Zsailer While discussing this question internally, I came with comparing the I can see 2 downsides to jupyter_notebook_entrypoint which can be mitigated:
|
We discussed this more in the Notebook meeting today. I agree with @echarles's characterization—jupyter_notebook_entrypoints is more of an "implicit" approach and opens the door for a different kind of confusion for users that might be more difficult to debug in the long run. I think we should stick with the "explicit" approach here in this PR. I also recommend that we spend some time during one of the Notebook Meeting calls and "dogfood" these changes a bit. We might find that we need to add some logging to the entrypoints in notebook and nbclassic to help users understand the difference. This will likely require a landing page with documentation explaining the relationship between these packages. Thanks, @echarles, for doing this work here! |
Fixes jupyter/notebook#6501
cc/ @Zsailer @RRosio @ericsnekbytes