Skip to content
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

Merged

Conversation

echarles
Copy link
Member

@echarles echarles commented Aug 8, 2022

@echarles echarles added the bug Something isn't working label Aug 8, 2022
@Zsailer
Copy link
Member

Zsailer commented Aug 8, 2022

Hm, this seems like it would lead to more confusion around the entry-points.

What if notebook_shim owned these entry-points, and we removed the entrypoints from both nbclassic and notebook<7?

Then, notebook_shim would attempt to load the underlying methods from nbclassic first, and fallback to notebook if not available.

@echarles
Copy link
Member Author

echarles commented Aug 8, 2022

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.

@Zsailer
Copy link
Member

Zsailer commented Aug 8, 2022

Actually, thinking about this more... why does nbclassic need to define these entrypoints at all? Shouldn't it just depend on whatever comes from the notebook package? I can't think of a good use-case for why you would want nbclassic to configure notebook extensions, server extensions, and bundlers separately from notebook. I think nbclassic should inherit all of these from the notebook package.

Nevermind... I just remembered that nbclassic doesn't depend on notebook anymore. Sorry for the noise.

@echarles
Copy link
Member Author

echarles commented Aug 8, 2022

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.

@echarles
Copy link
Member Author

@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?

@Zsailer
Copy link
Member

Zsailer commented Aug 12, 2022

Thanks, @echarles.

I'm still concerned with the degradation in the user experience here. We have already experienced a lot of confusion jupyter serverextension entrypoint:

jupyter serverextension ...

vs.

jupyter server extension ...

Now we are looking at adding another one

jupyter nbclassic-serverextension ...

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!

@echarles
Copy link
Member Author

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).


# Attempt to load form notebook v7 first.
# If using notebook v6 is installed, use that.
# If notebook is not installed, fallback to nbclassic.

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.

# Notebook shim to ensure notebook extensions backwards compatiblity.
try:
from notebook import version_info as notebook_version_info
except Exception:
notebook_version_info = None

@echarles
Copy link
Member Author

@Zsailer While discussing this question internally, I came with comparing the explicit approach (what this PR does) and the implicit approach (what jupyter_notebook_entrypoint is providing).

I can see 2 downsides to jupyter_notebook_entrypoint which can be mitigated:

  • As a user typing the same command (one of the entrypoints), I don't know what is effectively implicitly called. This can be mitigated by adding logs to tell the user which entrypoints in installed. I am not sure if some logs can be shown at runtime.
  • This is another package to release and notebook/nbclassic (with their branches) need to be updated. This package is not supposed to evolve, but the needed code (jupyter-releaser...) still needs to be setup.

@Zsailer
Copy link
Member

Zsailer commented Aug 17, 2022

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!

@echarles
Copy link
Member Author

Thanks, @echarles, for doing this work here!

Thx for the alternatives and discussions @Zsailer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Entry-point conflict between notebook <=6.5 and nbclassic
2 participants