Rename duplicate entrypoints

[echarles]

Fixes jupyter/notebook#6501

cc/ @Zsailer @RRosio @ericsnekbytes

[Zsailer]

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]

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]

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]

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]

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

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]

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.

nbclassic/nbclassic/__init__.py

Lines 10 to 15 in 33f5cbd

	# 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]

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

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]

Thanks, @echarles, for doing this work here!

Thx for the alternatives and discussions @Zsailer