[HN Gopher] JupyterLab 3.0
       ___________________________________________________________________
        
       JupyterLab 3.0
        
       Author : kylebarron
       Score  : 129 points
       Date   : 2021-01-05 16:19 UTC (6 hours ago)
        
 (HTM) web link (blog.jupyter.org)
 (TXT) w3m dump (blog.jupyter.org)
        
       | sgillen wrote:
       | I was really excited to see the visual debugger there. I tried it
       | myself, it was really easy to get it going. Unfortunately, using
       | it briefly in the notebook I was using I found it pretty buggy,
       | lots of glitches and big slowdowns in the UI. I would also really
       | love to see the option to drop into an interpreter while
       | debugging.
       | 
       | Still, can't complain too much about an open source project,
       | thanks to the team for all their hard work.
        
       | globuous wrote:
       | Nice ! Native debugger :)
        
         | linspace wrote:
         | Yes, debugging notebooks is not the best experience so I'm glad
         | there are improvements. I will have a look.
        
       | pavlov wrote:
       | I 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, but it couldn't
       | find any dependencies for the notebook. As a complete newbie to
       | the Python ecosystem, I googled for instructions and found
       | various environment managers, which then failed possibly because
       | something is incompatible with Big Sur. More googling revealed
       | instructions with complex CFLAGS environment setups to fix it,
       | which didn't -- and at that point it was very far from the
       | supposed convenience of scripting languages anyway.
       | 
       | I don't think it's Python's fault. Probably all the programming
       | toolchains are this hard to a newbie! But it was a humbling
       | experience after 34 years of programming, not being able to load
       | a piece of sample code in a Sunday afternoon.
        
         | bitanarch wrote:
         | 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
         | 
         | ```
        
           | davidf18 wrote:
           | You can download anaconda in either the command line or
           | graphical user interface versions selecting the versions of
           | Python you wish to install.
           | 
           | Then according to the blog posting for jupyterlab 3.0 execute
           | the following command:
           | 
           | conda install -c conda-forge jupyterlab=3
        
           | modriano wrote:
           | 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...
        
         | flaviocopes wrote:
         | Not sure about the Jupyter-specific issues but macOS comes with
         | Python 2 installed, so you have to install Python separately
         | and use the `python3` binary, or alias `python` to the
         | `python3` binary.
         | 
         | Then remember to run pip using `python3 -m pip <command>` and
         | use virtual environments (venv)
         | 
         | I stumbled on this a couple weeks ago and documented the
         | process here https://flaviocopes.com/python-installation-macos/
         | 
         | I found the same problem with Ruby (old version preinstalled on
         | macOS)
        
         | [deleted]
        
         | syntaxing wrote:
         | Always try using a virtual env. Also try using pip directly
         | through 'python3 -m pip install jupyter' . Same to run it to
         | bypass path issues 'python3 -m jupyter notebook'. You should be
         | up and running in a couple mins!
        
           | pavlov wrote:
           | These were among the suggestions that I tried. I think the
           | virtual env failed because of Big Sur, but not sure.
        
         | vmchale wrote:
         | > I don't think it's Python's fault. Probably all the
         | programming toolchains are this hard to a newbie!
         | 
         | Python is a little worse in that in pushes its dirtiness
         | downstream to your users too.
        
         | WrtCdEvrydy wrote:
         | Yeah, I use portainer and then load a docker image of Jupiter
         | and import the notebook there.
         | 
         | Dependency management hell isn't just a Javascript problem
         | these days.
        
         | turtlebits wrote:
         | Yeah I've had this issue in the past with Jupyter. Now I
         | generally look for docker images when I want to check out
         | something new.
        
         | unixhero wrote:
         | Just install this: https://www.anaconda.com/products/individual
        
         | paozac wrote:
         | True. I like Python, but the ecosystem can be very confusing
         | for a quick dive. It's easy to get lost between pyenv,
         | virtualenv, pipenv, pip, pip3, easy_install and friends.
        
           | fwip wrote:
           | Very true - further evidenced by the five or six different
           | approaches your sibling comments are recommending.
        
         | zelphirkalt wrote:
         | In a better world, the notebook you downloaded should have come
         | with a list of dependencies and have reproducible code in it.
         | That said, Python environment tools and package managers are
         | still in a state of flux. Some tools make it easier, but are
         | not helping much with reproducibility (plain venv + pip, but
         | only if you got all required system packages installed!), other
         | tools enable reproducibility, but have growing pains and are
         | more difficult to use or get working (pipenv, poetry).
         | 
         | If you are in luck, your required libraries and appropriate
         | versions are available as GNU Guix packages and you can use
         | that.
        
         | baldfat wrote:
         | Python is AMAZING and Awesome TILL You want to spread what you
         | are doing to more then one computer. Though I have to say I
         | love domain specific languages and personal enjoy Racket as my
         | most fun language to use. It is sad that this has gotten so
         | much worse over the years.
        
         | antpls wrote:
         | Not sure about Mac, but on Linux, you install some docker
         | images and it just works (modulo some docker flags to learn if
         | you don't already know docker)
        
         | yshvrdhn wrote:
         | can look into google colab to directly load the notebook. Link
         | : https://colab.research.google.com/
        
         | typomatic wrote:
         | 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., etc.
         | 
         | OSX and its tooling are just ridiculous. I have no idea to this
         | day how macs became the premier development environment.
         | 
         | As always xkcd has a comic for it: https://xkcd.com/1987/
        
           | jackson1442 wrote:
           | > I have no idea to this day how macs became the premier
           | development environment.
           | 
           | I've been editing a tutorial one of my coworkers wrote that
           | targets new Python users on Windows. From my findings, the
           | grass is not greener.
           | 
           | Granted, geospatial Python is somewhat of a mess, but a lot
           | of tools I have to use are somewhat messy forks of Unix tools
           | (looking at you, pyenv-win) with tons of incompatible
           | extensions. For development, Windows is the exception because
           | you can transfer just about anything from Linux to macOS.
           | 
           | On my Mac, I can easily install all of the Python packages I
           | need without needing to install Visual Studio, pipwin,
           | anaconda, etc. I have bash/zsh as my default system shell.
           | Maybe it's easier to native Windows users, but bash/brew is a
           | much better combination than anything I've found in Windows.
           | 
           | WSL is a step in the right direction, but it still feels
           | secondary. If a first-class terminal experience existed on
           | Windows, I have a strong feeling that it could be the premier
           | development environment, or at least closer to Mac.
           | 
           | Maybe I'm using it wrong, but it definitely hasn't been made
           | clear on how to use it right.
        
             | sangnoir wrote:
             | > I've been editing a tutorial one of my coworkers wrote
             | that targets new Python users on Windows. From my findings,
             | the grass is not greener.
             | 
             | Maybe check the _other_ other side (Linux) - I found the
             | grass is greener there - at least for Python (and
             | programming tools in general). I 'm very comfortable on the
             | command-line, and moving from a pure Linux environment to
             | OS X & brew felt like a huge downgrade, followed by random
             | annoyances that remind you you are using inferior, non-GNU
             | utilities:                 $ ls my_dir -l       ls: -l: No
             | such directory
             | 
             | _Really_ - Mac OS? I know its minor, but that 's just user-
             | hostile and it happens every few weeks; I can't get over
             | it.
        
             | analog31 wrote:
             | >>>> I've been editing a tutorial one of my coworkers wrote
             | that targets new Python users on Windows. From my findings,
             | the grass is not greener.
             | 
             | I've been using WinPython for a few years. It's the closest
             | thing to "just works" that I've found, and non-programming
             | colleagues have been able to install it successfully.
             | 
             | Because it works almost like an isolated "container," it's
             | also possible to test your code on a clean install of
             | WinPython to make sure it will run on someone else's
             | computer before you share it.
             | 
             | I don't know the technical difference between WinPython and
             | a true container, but you can have multiple WinPython
             | installs on one machine, and they don't interfere with one
             | another, or with a pre-existing mainstream Python
             | installation on the same PC. So you can share your stuff
             | without worrying about screwing up someone else's stuff.
        
           | [deleted]
        
         | fastball wrote:
         | Relevant XKCD.
         | 
         | https://xkcd.com/1987/
        
       | kbelder wrote:
       | 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?
        
         | greazy wrote:
         | I've seen it crop up here and there. I've used it a few times
         | and its really amazing how fast.
         | 
         | Afaik it's a drop in replacement for conda using the same cli
         | parse. Even has miniconda (micromamba).
        
           | laingc wrote:
           | Did you reply to the correct comment? I can't understand what
           | you're referencing here.
        
       | losvedir wrote:
       | Hmm, what is mamba? I thought I was at least sort of up to date
       | with the various python dependency managers, but that one is new
       | to me.
       | 
       | Relatedly, I have a grand vision of having as part of my
       | development environment a jupyter notebook always at hand, in
       | which to explore data as necessary, whip up scripts, accumulate
       | little helper functions, etc. Basically, any time I have that
       | "hm, I wonder..." itch, I'd like to be able to quickly whip up a
       | solution in my notebook. I'm a skilled developer in terms of
       | larger systems, but have a weakness when it comes to very early
       | stage "throwaway" scripts to answer ad-hoc questions.
       | 
       | I spent a few days trying to set up jupyterlab in an "ideal" way,
       | so that I could have easy access to python libraries within my
       | notebook, and also a reproducible environment since I plan to
       | push my working directory to GitHub and would like to sync across
       | different machines. I got confused by virtualenv vs venv, and
       | tried conda to install libraries, but ran into various problems.
       | Oh, and part of it was trying to have nbdev (from the fastai
       | folks) as part of this toolkit.
       | 
       | Anyone have a setup like this that they use and want to share?
       | Part of me wants to just throw in the towel and learn R and
       | RStudio, since I've heard its ggplot is the best plotting library
       | anyway.
        
         | liuliu wrote:
         | I have an unconventional setup of Jupyterlab, Python
         | dependencies, Swift (through PythonKit package) with Bazel.
         | Surprisingly, the new `rules_python` and `pip_install` support
         | works great at installing packages through pip. This ensures on
         | any machine, I will have a consistent Python runtime (either
         | downloaded or build from the source), as well as the pinned
         | python dependencies when the repo checked out. It also helps
         | because I have a Swift kernel that packaged inside the repo as
         | well.
         | 
         | One thing I haven't figured out is about Jupyterlab's extension
         | system, which previously requires node.js for delivery. It
         | seems 3.0 removed that requirement, so I am hopeful with some
         | tuning I can deliver the plugins in consistent way as well.
        
           | zhengyi13 wrote:
           | Neat! I don't suppose you've got your BUILD and WORKSPACE up
           | somewhere you wouldn't mind sharing?
        
         | abdullahkhalids wrote:
         | On linux, I install Anaconda and just launch JupyterLab from
         | Anaconda Navigator.
         | 
         | But you could just install conda and just `conda env export -n
         | base` to export your environment.
        
         | BadInformatics wrote:
         | mamba is (nominally) a drop-in replacement for Conda's CLI and
         | dependency resolver. I've been using it for a couple of months
         | and it really does run an order of magnitude faster for
         | anything that requires dependency resolution. You'll still want
         | to keep ana/miniconda around, but it goes to show how some of
         | Conda's performance woes are entirely self-inflicted.
        
         | nxpnsv wrote:
         | Mamba is a reimplementation of the conda package manager in
         | C++. (quote from README at https://github.com/mamba-org/mamba,
         | linked to in original post)
        
           | vlgnat wrote:
           | Funny, Python is too slow for a package manager and most
           | people who can write fast C extensions have left the scene.
           | 
           | So C++ is the natural choice.
        
             | remram wrote:
             | Not sure if I agree with you but I was very surprised to
             | find that their Python kernel is also implemented in C++:
             | https://github.com/jupyter-xeus/xeus
        
             | roseway4 wrote:
             | > most people who can write fast C extensions have left the
             | scene
             | 
             | Care to elaborate?
        
         | klelatti wrote:
         | Have you looked at any of the Jupyter Docker Stacks images? [1]
         | 
         | I've built some personal Docker images based on these with
         | quite a lot of additional features installed including Ruby,
         | OpenCL and lots of additional Python and R packages and
         | JupyterLab extensions. It's been a bit hit and miss - with
         | extension incompatibilities being a bit of an issue. I sync
         | directories on the host machine with the Docker image and so
         | have the benefit of editing in a full text editor (for non-
         | notebook scripts).
         | 
         | I'm not a Python env expert so I've probably missed a few
         | tricks but all seems to be working well now. Happy to help if
         | you want to try this route and have any issues.
         | 
         | Btw after using JupyterLab for over a year now I'm a huge fan.
         | 
         | [1] https://jupyter-docker-stacks.readthedocs.io/en/latest/
        
         | iamlucaswolf wrote:
         | I use a setup like this. Essentially, I use pyenv [1] to manage
         | Python versions and Poetry [2] [2](https://python-poetry.org/)
         | for virtualenvs/dependencies.
         | 
         | The workflow for creating a new project looks like this:
         | 
         | 1. Create a project directory (e.g. 'myproject') and `cd` into
         | it. 2. `git init` 3. Fixate the Python version for that project
         | with the `pyenv local` command (e.g. `pyenv local 3.8.6`). This
         | creates a `.python-version` file that you can put under source
         | control. Within the `myproject` directory tree, `python` will
         | now be automatically resolved to the specified version. Your
         | system Python (in fact, any other Python versions you might
         | have installed) remain untouched. 4. Create a new poetry
         | project (`poetry init`). This creates a `pyproject.toml` which
         | contains project metadata + dependencies and can also be
         | checked into git. 5. Add dependencies with `poetry add`. Here,
         | you could for instance add Jupyter Lab (`poetry add
         | jupyterlab`).
         | 
         | To access installed dependencies, such as the `jupyter lab`
         | command, you can either execute one command in the virtualenv
         | directly (`poetry run jupyter lab`) or spawn a shell (`poetry
         | shell`). If you open a Jupyter Notebook that way, the packages
         | installed in the virtualenv are directly available from within
         | Jupyter Notebooks, without having to mess around with
         | installing IPython kernels.
         | 
         | I like this approach, because it gives you full flexibility,
         | while being portable and easy to use. It gets you around having
         | to deal with conda (which I found to be frustrating at times).
         | Also, you're not tied to the Jupyter frontends, but could e.g.
         | just install `ipykernel` and open notebooks in VSCode.
         | 
         | [1](https://github.com/pyenv/pyenv/) [2](https://python-
         | poetry.org/)
         | 
         | Edit: Moved the links
        
           | claytonjy wrote:
           | I do very similarly, except I avoid installing jupyter lab
           | for each project, instead installing `ipykernel` as a dev
           | dependency. I install jupyter lab system-wide with pipx [1],
           | and for each project issue a command like
           | pipenv run python -m ipykernel install --user
           | --name=this_directory
           | 
           | Then if I open Jupyter Lab I see "this_directory" as a listed
           | kernel to create a notebook from.
           | 
           | This allows me to manage Jupyter settings and plugins in one
           | place rather than in each env, have multiple project's
           | notebooks open in the same Jupyter Lab instance, etc.
           | 
           | [1]https://pipxproject.github.io/pipx/
        
       | klelatti wrote:
       | Just 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.
        
       | colincooke wrote:
       | Ok 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!
        
       | hnews2 wrote:
       | I've seen a few projects that have used the JupyterLab UI for
       | other projects as a simple interface - it looks really neat and
       | slick.
       | 
       | I just wondered if anyone has any ideas how you go about this as
       | I've been drawing a blank.
        
         | klelatti wrote:
         | Could you share any examples of what you've seen?
        
       | bobbylarrybobby wrote:
       | I don't understand why Jupyter notebooks are still in use as a
       | writable format when there are editors like VSCode that can treat
       | ordinary python files as notebooks. The Python extension can
       | submit code blocks to the kernel and import and export Jupyter
       | notebooks, but VSCode is also a real editor on top of that
       | (debugging, git, vim mode, hover info, etc.). For distribution,
       | as a read-only format (like PDF), notebooks are great. But why do
       | people continue to do their work in one?
        
         | kaba0 wrote:
         | Maybe I misunderstand something, but I use jupyter for sage for
         | example and the point of it is that graphical results can be
         | shown there immediately. Some plots can be even made
         | interactive.
        
           | bobbylarrybobby wrote:
           | When running a Python kernel, VSCode splits the editor into
           | two panes, the input .py file pane and the output ipython
           | pane. The output pane supports interactive graphs just like
           | Jupyter does.
        
         | alex-treebeard wrote:
         | > why do people continue to do their work in one? Most nb users
         | don't use vscode. I'd say main reason is you can't open a
         | notebook without starting a kernel which takes >1 second. It
         | also is harder to setup.
         | 
         | In terms of a flat file formats, there is actually a mark down
         | extension which I would say is better than vscode's format
         | because it is more standardised:
         | 
         | https://myst-nb.readthedocs.io/en/latest/
        
         | ajford wrote:
         | 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 write python software and the
         | software is the end result and not the data analysis/process, I
         | think you might be doing it wrong.
         | 
         | Not that I'm discounting data scientists (or the like) who use
         | it as their primary environment. Their end result is not a
         | packaged/deployed software and the code itself is just
         | ancillary. For those users, the code and environment is a tool,
         | and the extra weight of what a full IDE (like VSCode or
         | PyCharm) and the features they bring to the table are
         | unnecessary and likely counter-productive.
        
       | jjcon wrote:
       | Interesting that they include mamba install instructions before
       | conda.
       | 
       | Is mamba taking off with the recent (and upcoming) license
       | changes that anaconda made? I'm not familiar with mamba though
       | I've had my eyes open for an alternative to anaconda (also seen
       | poetry mentioned a few times here).
        
       ___________________________________________________________________
       (page generated 2021-01-05 23:01 UTC)