Option to package notebook but not via github?

[Justyouraveragehomie]

Hi there, I literally just asked this question to myself the same day you published your paper....

https://discourse.jupyter.org/t/is-there-a-way-of-converting-a-jupyter-notebook-with-widgets-to-a-desktop-application/38455

And here: nteract/desktop#718

It would be great if you add a feature where users do not have to upload their code to github to convert it to a desktop application....is this planned at all?
Alot of people would not want to upload their code to github if their end goal is distribution.

Also I should mention im coming from the voila side of things, so id actually be more curious to know if there is a non-toggle option for auto hiding of the code cells for people who wish to only show the dashboard to the user within the application. Aka, zero code exposure.

[IvanHCenalmor]

Hi @Justyouraveragehomie!
Sorry for the late reply, it has been a busy week 🫠

First of all, about not uploading their code to GitHub. We were not initially considering it, as GitHub with the free GitHub actions facilitates a lot the process and some of the functionalities relay on it. Still, after your comment we might reconsider it and if you think that many people would not like to upload their code to GitHub, we might look into how this could be done. Just out of curiosity, why wouldn't you like to upload the code to GitHub? If you don't want people to see your code you could just keep your repository private.

I would like to let clear the benefits of using GitHub (and the reason why we went with it) and the features that you would be loosing for not using it.
What GitHub provides:

• Free GitHub actions on different operative systems (OS). These actions are now used to: do a version checking of the notebooks, validate that the python environment does not give dependency conflicts, automatise many of the updates (on including external code or notebooks) and build the executable for each OS.
• You would have a collaborative space where multiple people could work on (on contributing or updating notebooks).
• On the welcome notebook that is launched with the app, you would have a version controlling of end users, letting them now if the notebook that they are using is the latest one. This feature is enabled because a version track is given by the GitHub actions and because the version checking is done by comparing the local version with the online one (on GitHub).
• You can choose the visibility of your repository (public or private) and in case of private you could choose with whom you could share it. Full control.
• You can customise your repository and upload your notebook with the provided web form (https://labconstrictor-form.streamlit.app/).

Therefore by not relying on GitHub what you would loose or what you would need to do is:

• First of all and the biggest problem is that you would need to create the executable files yourself. This requires for you to set up a Python or conda environment with the main dependencies for its construction. You would also need to create the executable this on three different OS (Windows, macOS and Linux-based) in order to be cross-OS compatible, unless you only want it in one OS.
• The customisation of the template repository and the updates that you need to make when you need add a notebook (or if you want to include external code) would also need to be done manually.
• The welcome notebook would only guide you to the notebooks and would not provide any version checking.

Let me know what you think, but many of the nice features that LabConstrictor provides are thanks to the automatic processes based on GitHub. Not relying on them would make the process less user-friendly.

[IvanHCenalmor]

About a non-toggle option to avoid showing the code. We were initially considering the voilà option for the zero code experience, but at the end we did not go for that option as voilà requires to run the whole notebook before displaying it. This is not an option for many notebooks that need step by step interaction and where the execution of a code cell relies on an input given on previous code cells.
We still think that the combination of the toggle button of hiding/showing the code with the play button next to the code cell is a nice zero-code exposure strategy that would solve previously mentioned situation. On the initialisation form, you can choose between displaying or hiding the code on your notebooks. So, by simply choosing to hide the code you would get the zero code exposure that you like. Additionally, the option to toggle your code visibility allows users to check the code that they are running if the they want to, this would allow them to validate what the code is actually doing or if they want to make some changes to your code. Unlike the collapse option that Jupyter Lab provides by default, now when your users click on the code cell, this one is not uncollapsed.

[Justyouraveragehomie]

Thanks for the response, that all makes complete sense. With private repositories it would totally work.
I'm looking to build the executable offline, without gathering my libraries online, since I have some custom ones.
I realize this goes against the whole point, considering your project is for people who have nothing installed on their ends.
At the moment I was only looking to build for windows....but I would eventually need to build for mac in the future as well.
I was hoping for a single executable that opened the notebook as a program window dashboard, in this case voila would be my dependency. An example is the dead library: https://github.com/JoelStansbury/widgetron
If you do consider having a zero code option...or a voila-type option, that would be super awesome.
It's mostly being able to package my dashboard (widgets and such) into an exe that im after.