I skimmed the page and didn't see any mention of sharing or collaborative use. That's the biggest obstacle I'm seeing with getting buy-in at work. I need to be able to let some users see the notebook in read-only mode, others should be able to run it but not edit it, others should have full access. Maybe there's a non-hacky way to do this and I'm missing it?
JupyterLab 3.0
81–90 of 145 posts
Re: JupyterLab 3.0
#82Just to say a big thank you to all those who have worked on JupyterLab. It's by far my favourite notebook interface and I think gets the balance between a clean interface and powerful features just about right. I just wish that the cloud providers would adopt it as the basis for their products.
It’s not a basis for their products but this is something https://colab.research.google.com/notebooks/intro.ipynb#rece...
Re: JupyterLab 3.0
#83Earlier quoted context omitted.
I don't think anyone who writes production code is using Jupyter as a development env. It's more like a self-documenting, persistent repl, or perhaps an interactive doc. I've used it as a way to document data exploration for later use and as an interactive teaching tool. For that, being able to plot inline and embed interactive widgets is great. Also, mixing in rendered markdown content. If you're using Jupyter to wr…
> Not that I'm discounting data scientists (or the like) who use it as their primary environment. Unfortunately it often ends up needing to be executed as a batch job or integrated into a pipeline, which then starts the fun job of extracting the code from the notebook piece by piece. Jupyter having a plain text file format instead of json would make life so much easier, and vastly improve version control.
For batch jobs you have papermill, for plaintext format you have the jupytext extension that pairs the Jain notebook with a script with notebook markup in comments. I honestly wish that they had used that format as just being the notebook format, but it’s a nice enough and easy fix.
Re: JupyterLab 3.0
#84Great news! I'd only just updated the Purple Please theme[1] for Jupyter Lab 2.0, will have to look at doing the same for Jupyter Lab 3.0. It looks like they've made some improvements to extension development too which is good to see.
[1] https://datacrayon.com/posts/tools/jupyter/theme-purple-plea...
Re: JupyterLab 3.0
#85Earlier quoted context omitted.
You should use Anaconda instead of pip to install data science related tools in Python. ``` $ conda create -n {new_environment_name} python $ conda activate {new environment name} $ conda install jupyterlab ```
You also have to manually add the kernel for that environment via: ({new_environment_name}) ...$ python -m ipykernel install --user --name {new_environment_name} --display-name "Python ({new environment display name})" The env won't be accessible in jupyter (lab or notebook) until you do this step. [0] https://stackoverflow.com/questions/39604271/conda-environme...
Nope, what he wrote works just fine at least for conda. That advice is only if you want to be able to choose environments as kernels in the frontend. If you just run jupyter lab/notebook in a conda env which has it installed, the default kernel will be in the activated environment.
Re: JupyterLab 3.0
#86Earlier quoted context omitted.
I have used Python on OSX for years and it is and always will be a horrorshow. Using the system Python installation is a nonstarter for many reasons, chief among them is that I don't have any interest in using py2. So then you're using pyenv or homebrew, but your vim install still thinks that it should be using the system python. And whoops, you fixed that and now virtualenv is not finding your interpreter. And etc.,…
> OSX and its tooling are just ridiculous. I have no idea to this day how macs became the premier development environment. Because: (a) it's quite easy to set things up with brew, macports, and/or Nix (b) because Python is shitty everywhere anyway, and Python isn't the be-all end-all of development work. (c) because you get a full-featured, working, coherent, take-it-or-leave-it desktop that stops one way of endless…
b and g are mutually exclusive, though?
Re: JupyterLab 3.0
#87Ok this may be kind of stupid, but my primary reason for not switching over to jupyter lab (from notebooks) was the right-click menu wouldn't let me copy images (plotting outputs typically) from the in-line output. However I found out today that it has always been available if you hold shift...so if that was anyone's issue this is a great time to give JupyterLab another shot!
That was an explicit decision in the underlying UI toolkit, which supports overriding the context menu in a generic way, to move the browser's default context menu to Shift-Click.
Re: JupyterLab 3.0
#88Earlier quoted context omitted.
> OSX and its tooling are just ridiculous. I have no idea to this day how macs became the premier development environment. Because: (a) it's quite easy to set things up with brew, macports, and/or Nix (b) because Python is shitty everywhere anyway, and Python isn't the be-all end-all of development work. (c) because you get a full-featured, working, coherent, take-it-or-leave-it desktop that stops one way of endless…
b and g are mutually exclusive, though?
Not in any logical sense (e.g. violating any Logic rule). They just cover different use cases.
(b) makes the "macOS is particularly bad for development because I found Jupyter/Python deps difficult there" argument moot, as messed up Python dependencies are the case in Windows and Linux as well.
And (g) says that Docker and co has superceded manually setting up Python environments for many (not necessarily all or even most) devs, mitigating concerns about managing multiple local versions different deps/libs/language versions to work with different projects (since you can now do that in different, isolated, virtual environments which are mini-OSes in themselves).
So (b) basically amounts to: "It's not macOS which is makes Python deps shitty, they are inherently shitty".
And (g) basically amounts to: "Since Docker and co make local development dep issues mostly obsolete, even if macOS was bad at local deps, it wouldn't matter as much today anyway as virtualization levels the field".
And of course, with the field levelled by (g), if you go for virtualized dev envrironments, you still get all the other benefits like e, f, c, and d.
Re: JupyterLab 3.0
#89I don't write Python code for my work. Last weekend I came across an interesting Jupiter notebook and figured I'd give it a try on my work laptop. "It's probably as easy as brew install pip and then use that to load the other dependencies," I assumed. Over an hour later I had to give up. There was initially some kind of Python version conflict on my Mac. Eventually some version of JupyterLab was installed somewhere,…
I'm in the same boat. That's why I use repl.it[0] for nearly all my programming now. Haven't tried jupyter on repl.it, but here's[1] the first DDG result, which suggests jupyter is supported.
[0] https://repl.it/ [1] https://repl.it/talk/templates/Jupyter-Notebook/49993
Re: JupyterLab 3.0
#90I don't write Python code for my work. Last weekend I came across an interesting Jupiter notebook and figured I'd give it a try on my work laptop. "It's probably as easy as brew install pip and then use that to load the other dependencies," I assumed. Over an hour later I had to give up. There was initially some kind of Python version conflict on my Mac. Eventually some version of JupyterLab was installed somewhere,…
I find that everything in Jupyter-land is as inconvenient to reproduce as it is convenient to experiment with. Case in point: last I checked, you still had to do gymnastics in order to even store your notebooks in Git in a meaningful way (e.g. allowing merges).
It really throws me off the whole thing (Julia + Jupyter is even worse...) because I’m not keen on putting effort into stuff that nobody, myself included, will be able to use in a year or two.