jupyter deno notebook - ffi issue about deno HOT 4 OPEN

I have the same issue when using Deno from the Ubuntu Docker image, [denoland/deno:ubuntu-1.41.0]. Is there some reason you don't use their official docker images (https://hub.docker.com/r/denoland/deno) ? I'm new to Deno and I'm asking to see if I missed something.

In my case this fails with the same message when trying to import from skia_canvas.

I see on their repo the make an explicit note to use specific flags allowing unstable ffi content but I could not use that with Jupyter.
https://github.com/DjDeveloperr/skia_canvas?tab=readme-ov-file#usage

I also see that the Deno-Jupyter-D3 combination has been working in the past since this code is present in multiple example articles.

from deno.

articles

Hello @sergiunagy thank you for your message:

• I do not use the official ubuntu image, because i always prefer debian for deeply technical things: the debian community is more serious in their publications, usually, and for all documentation. Also Debian is very sttable and solid globally
• As of today, I still have the exact same issue: I am not yet able to say why the ffi lib feature wouldn't work even though I tried all usage of the unstable ffi flag I could think of yet.
• the only thing I could thinkof is that there might be a lack of linux packages underneath: as you can see in my docker image, i tried many combinations, yet for now i couldn't make it work:
  • my most natural idea would be to start from a deno official image, where unstable ffi flags should work
  • yet it's a hassle to properly intallthe full python stack required by jupyter: so its gonna take time, before i complete taht, and i have other responsibilities in my project, so well, if you have news i'm really a taker...

from deno.

I have the same issue when using Deno from the Ubuntu Docker image, [denoland/deno:ubuntu-1.41.0]. Is there some reason you don't use their official docker images (https://hub.docker.com/r/denoland/deno) ? I'm new to Deno and I'm asking to see if I missed something.

In my case this fails with the same message when trying to import from skia_canvas.

I see on their repo the make an explicit note to use specific flags allowing unstable ffi content but I could not use that with Jupyter. https://github.com/DjDeveloperr/skia_canvas?tab=readme-ov-file#usage

I also see that the Deno-Jupyter-D3 combination has been working in the past since this code is present in multiple example articles.

add on : ouh oh my, you must pass --allow-env, --allow-ffi and --unstable-ffi flags , i will try using together all 3, i haven't tested that yet, thanks for the ref @sergiunagy !

from deno.

I have the same issue when using Deno from the Ubuntu Docker image, [denoland/deno:ubuntu-1.41.0]. Is there some reason you don't use their official docker images (https://hub.docker.com/r/denoland/deno) ? I'm new to Deno and I'm asking to see if I missed something.

In my case this fails with the same message when trying to import from skia_canvas.

I see on their repo the make an explicit note to use specific flags allowing unstable ffi content but I could not use that with Jupyter. https://github.com/DjDeveloperr/skia_canvas?tab=readme-ov-file#usage

I also see that the Deno-Jupyter-D3 combination has been working in the past since this code is present in multiple example articles.

Hello again @sergiunagy , a bit more to answer you:

• first, in the denoland/deno you mention, the typescript/deno source code you talk about is executed directly by deno. But in my case, I want to execute the same source code (involving skia_canvas), but in a jupyter notebook, with a deno kernel. In denoland/deno, there is nothing related to jupyter at all, it is just a bare deno runtime.
• Yet, thank yiou for yoru feedback: it makes sense, that the deno runtime, whether bare, or as a jupyter kernel, spits the same error, about this skia_canvas source code we are interested in.
• Starting the jupyter app, inside a container, is done running a jupyter command, would it make sense to feed the jupyter command, deno GNU options? Well, you can see below a few tests I have performed, all ended up either jupyter failing to start, or the skaia_canvas causing the same ffi related error :

#!/bin/bash

export PATH="$PATH:$HOME/.cargo/bin"
source ~/.bashrc

pwd

cargo --version


deno --version
# KO # deno jupyter --install --unstable-ffi --allow-ffi --allow-env
# KO # deno jupyter --install --unstable-ffi --allow-env
# OK but does not fix [ffi dl open] error # deno jupyter --install --unstable-ffi --unstable --unstable-fs --unstable-worker-options
deno jupyter --install --unstable-ffi --unstable-fs # without [--unstable] which is deprecated for [--unstable-*] options
# deno jupyter --install --unstable-ffi

# tested works # jupyter notebook --unstable true --ip 0.0.0.0 --allow-root
export NOTEBOOKS_DIR=$DATAVIZ_NOTEBOOKS_HOME
# OK # jupyter lab --unstable=true --ip=0.0.0.0 --allow-root --NotebookApp.token='decoderleco' --NotebookApp.password='decoderleco' --notebook-dir="$NOTEBOOKS_DIR"
# KO # jupyter-lab: error: unrecognized arguments: --unstable-ffi=true --unstable-fs=true # jupyter lab --unstable=true --unstable-ffi=true --unstable-fs=true --ip=0.0.0.0 --allow-root --NotebookApp.token='decoderleco' --NotebookApp.password='decoderleco' --notebook-dir="$NOTEBOOKS_DIR"
# KO # jupyter-lab: error: unrecognized arguments: --unstable-ffi --unstable-fs # jupyter lab --unstable=true --unstable-ffi --unstable-fs --ip=0.0.0.0 --allow-root --NotebookApp.token='decoderleco' --NotebookApp.password='decoderleco' --notebook-dir="$NOTEBOOKS_DIR"
jupyter lab --unstable=true --ip=0.0.0.0 --allow-root --NotebookApp.token='decoderleco' --NotebookApp.password='decoderleco' --notebook-dir="$NOTEBOOKS_DIR"

Finally, I could do some more tests, finding out how one can configure jupyter to pass arguments and options to a jupyter kernel. But if it does not work with a bare deno, there is not one chance it would as a jupyter kernel: so trygin tests with a bare deno runtime is lighter, ad faster.

Now the question is : what more tests can we do ?

I say this:

• first lets not forget what --unstable-ffi: it means this ffi feature might disappear anytime in future versions of deno. This also means that iff it does not work with todays latest version of deno, it certainly was working in a previous version of deno : at the date the article/blog posts were pulblished, what was the latest version of deno ...?
• the only one other parameter we can play with in tests, is the following: the linux packages installed "under" the deno installation: things like libffi-dev and a few others, might be required, and are missing in some containers

WDYT?

Could we join efforts to design a whole set of tests and catch this animal together ? the question and reached hand is meant at all readers as well.

ps:

For the reference:

• #15674

from deno.