yWorks / yfiles-jupyter-graphs

The home of the Jupyter notebook graph visualization widget powered by yFiles for HTML
https://www.yworks.com/products/yfiles-graphs-for-jupyter
Other
162 stars 15 forks source link

PyPi package currently installs as `yfiles-jupyter-graphs` rather than `yfiles_jupyter_graphs` #8

Closed Jim-Salmons closed 2 years ago

Jim-Salmons commented 2 years ago

Describe the bug PyPi package currently installs as yfiles-jupyter-graphs rather than yfiles_jupyter_graphs. The dash chars are a syntax error and breaks imports. All package examples reference the syntactically correct underscore package name.

To Reproduce Steps to reproduce the behavior:

  1. Install as described on the PyPi.org pkg page or the GitHub repo's readme.
  2. The installation will result in the dash-named package even if you request the underscore named package which processes but gives you the dash-named package.
  3. Try to run an example and it can't find the named package.
  4. Rename example to match the dash-named installation and you get a syntax error halt to execution.

Expected behavior Installing should result in yfiles_jupyter_graphs package install.

Desktop (please complete the following information):

fskpf commented 2 years ago

Unfortunately, the entire underscore vs dash topic in python modules and packages is a nuisance and source of confusion. To make it even worse, the build tools and PyPI perform implicit name normalization on top of it.

This question (and the response) explains it a bit more profoundly.

However, I think what you describe works as expected and is not a bug:

The installation will result in the dash-named package even if you request the underscore named package which processes but gives you the dash-named package.

AFAIK, this is expected because the name is normalized along the way. This thread gives some context about it. Additionally, the toolchain for the Jupyter package templates (which we also use for this extension) comes with setuptools that also normalizes the package name during the build. In fact, we already pass yfiles_jupter_graphs as name to the build process.

Rename example to match the dash-named installation and you get a syntax error halt to execution.

This is expected. Dashed imports are always syntactic errors because Python parses the name context-free and dashes are interpreted as the mathematical operator instead of string characters. So even if the package name is listed with dashes, it should be imported with underscores.

Installing should result in yfiles_jupyter_graphs package install.

As mentioned above, I think this works as expected and should not show up as yfiles_jupyter_graphs due to how the toolchain is set up and how the registry works.

Supposedly, the recommended solution to this topic in general is to use all-lowercase names without any form of delimiter, which was not an option for this package.

Does it work on your end when you import the package just like in the provided examples, i.e. with yfiles_jupyter_graphs?

Jim-Salmons commented 2 years ago

Okay... thanks for the info. Am cleaning my conda caches and packages, removing envs that installed the 'dash-named' module and trying again while paying more attention and capturing steps of what I do. Will report results soon.

Jim-Salmons commented 2 years ago

Okay... After cleaning cache and packages, deleting the bad env, and creating a clean conda envs by both pip install yfiles_jupyter_graphs andpip install yfiles-jupyter-graphs, then running jupyter notebook via terminal and accessing by browser, everything worked as expected. :-)

I believe that my issue surfaced by trying to install and then run the examples within VSCode. Try as I might, my attempts to recreate the issue today could not replicate the problem seen last night. The only gotcha I have is that running the examples with VSCode do not render the impressive yfiles_jupyter_graphs GraphWidget. :-( This does not appear to be your problem but is rather a limit of VSCode Jupyter support or my lack of knowledge as to how to configure and run Notebooks within VSCode.

So I am closing this issue now. Thanks for the helpful information to put me on the right track. I only wish I could get yfiles_jupyter_graphs rendering in VSCode. :-/

fskpf commented 2 years ago

I find the name handling in the ecosystem still quite confusing and my comment above is also kind of a reference for my future self when I'm wondering why it is how it is.

About VSCode, this is currently not supported by the extension, see issue https://github.com/yWorks/yfiles-jupyter-graphs/issues/1 We notice that this is a common way to use Jupyter Notebooks and want to support it in the future, if possible.

Jim-Salmons commented 2 years ago

As I looked into the VSCode situation a bit deeper, I get this error message when running an example notebook:

Unable to find widget 'yfiles-jupyter-graphs' version '^1.1.0' from configured widget sources ["jsdelivr.com""unpkg.com"]. Expected behavior may be affected. Clickherefor more information.

I updated my settings.json as recommended on the above here-linked page, but still got the error message. Reading closer that advice page says if you update settings as recommended and still get the error, it likely means that the configured sources cannot find the specific version (yfiles-jupyter-graphs) asked for which would be ^1.1.0 in our case.

Is it possible that jsdelivr and UNPKG don’t have the latest release to serve? If these sources are up to date, then it would seem that VSCode is still having trouble handling the ipywidgets extension.

fskpf commented 2 years ago

Thank you for the details. You are correct, yfiles-jupyter-graphs extension is currently only available via the PyPI registry. Providing it on the CDN(s) should be rather easy, though it needs a different kind of bundle. But other than that, there are also some technical things to be considered as yGuy mentioned in #1. Particularly, the interactive nature of the extension with its UI could be a problem as it depends on how the embedding in VSCode is implemented.

Anyhow, we've not yet had the time to really dive deep into the issue, though it's the next topic we want to have a look at when there is some time to spare.

Just to keep things tidy in here, I'd suggest switching to the other issue (#1) for further discussions about the VSCode integration. It'd also help to upvote the issue, to state your interest in VSCode support, and to keep posted about updates on the topic.