I am currently looking into the Pyvisco library for my company. They however do not want to use the provided Binder build to process the data due to security concerns. That’s why I’ve been taking a look at running it locally using Jupyter lab. However when I try to upload the data within the application, nothing happens. No error, no confirmation, nothing. I am also unable to continue within the program. The exact same thing happens when I run it using Vscode. When using the provided Binder however, everything works just as expected. What could be the reason for it working with Binder but not with Jupyter lab and Vscode? Any help would be appreciated
You are reading the content into memory in the kernel with this ‘Upload’ step. When I run the .ipynb file in Jupyter NbClassic (see below) in the MyBinder-served session, I see feedback in green of ‘Upload Successful!’. I was using the file freq_Eplexor_master.xls in the provided examples and leaving the toggles at the default setting. I would think if you see the ‘Upload’ button rendered on your system this should work. I assume you see the button rendered when you run it local? Are you using the example data provided to make sure it isn’t your data it doesn’t like?
What version of JupyterLab are you trying this in? I had issues with the one that currently comes up in that MyBinder session (v3.4.8) where the widgets don’t render, while it worked locally in JupyterLab (v3.5.3) that I had from an older install of the Anaconda Distribution, see below under ‘Trying locally’. The main development work period (2 years ago, it seems) on pyvisco seems to pre-date JupyterLab 4 and Jupyter Notebook 7+ and current ipywidgets and so I wouldn’t be surprised if there are some rough edges if you are trying with the most current tech available. Also, I should mention I am surprised a bit it doesn’t work in JupyterLab in the MyBinder session but ipywidgets can be tricky to get working and I haven’t investigated why ipywidgets don’t render. It may be an environment issue. But locally your widgets render, right?
The perhaps easier way to look into using pyvisco locally is covered below the portion of ‘Usage’ section highlighting the MyBinder route:
“Alternatively, pyvisco can be installed automatically into Python from PyPI using the command line.”
And perhaps most importantly, below that it says:
" Additionally, the verification subfolder contains example Jupyter notebooks on how to use the library."
Have you tried to run those notebooks on your local system? I was able to at least run the first 10 or so cells in JupyterLab from the same MyBinder session when I used editing the URL to switch over to using JupyterLab and opened those notebooks after I ran mv verification/* . in the terminal first to put them in the same directory with the pyvisco module directory. My thinking is that perhaps you can work out how to use the package that way and then apply it to your data?
In fact, what I see looks a lot like the data I see when I run the LinViscoFit.ipynb file in Jupyter NbClassic interface and so I think this may be the best way to go because there you can see the files it is using and transpose the use of those to the filepaths on your local system, instead of relying on the in-memory situation to feed in the data.
(Note to others investigating: I wasn’t able to use the original notebook backing the Voila app in JupyterLab in the MyBinder session. I could run it and get the plots to generate and even package up a zip of the results in-memory to download from the original notebook by switching to the classic interface Jupyter NbClassic interface using the URL [needed token it seemed to do this] and I had to run some of the initial cells a couple of times to get the widgets to show up. YMMV, especially since it worked locally with JupyterLab 3, too [see under ‘Trying locally’ below].)
Trying locally
On my local machine, the LinViscoFit.ipynb demo page (same one that comes up by default in the Voila launch from the pyvisco repo) worked fine in Jupyter Notebook 6.5.2 and JupyterLab v3.5.3 that I had because I have an older version of Anaconda installed at present. (I used the same demo process and input data as I described above.)