Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JupyterLab 3.0

blog.jupyter.org

Post reply on HN
Print view View original

51–60 of 145 posts

Re: JupyterLab 3.0

#51

Post by bobbylarrybobby »

kaba0 wrote: post #45
bobbylarrybobby wrote: post #42

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…

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.

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.

Re: JupyterLab 3.0

#52

Post by sangnoir »

jackson1442 wrote: post #33
typomatic wrote: post #20

Earlier 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.,…

> 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 devel…

> 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.

Re: JupyterLab 3.0

#53

Post by zelphirkalt »

pavlov wrote: post #14

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,…

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.

Re: JupyterLab 3.0

#54

Post by abdullahkhalids »

bobbylarrybobby wrote: post #51
kaba0 wrote: post #45

Earlier quoted context omitted.

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.

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.

1. That's still less intuitive for someone who wants to understand the relationship between the code and output.

2. Following from 1, notebooks are meant to be shared with output in place, so others can understand without executing code.

Re: JupyterLab 3.0

#55

Post by deepsun »

pavlov wrote: post #14

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,…

No problems on Linux. I use pyenv for managing python versions and virtualenvs.

Re: JupyterLab 3.0

#56

Post by ahupp »

klelatti wrote: post #32
hnews2 wrote: post #27

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.

Could you share any examples of what you've seen?

This one uses JupyterLab as a frontend for CadQueury, a porcedural CAD system.

https://github.com/bernhard-42/jupyter-cadquery

Re: JupyterLab 3.0

#57

Post by klelatti »

bobbylarrybobby wrote: post #42

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…

I think you're suggesting that if you want to retain both code and results you need to manage two different files - raw python and exported notebook. I think many notebook users would see that as inconvenient (and many are not familiar with VSCode).

Re: JupyterLab 3.0

#58

Post by kristjansson »

pavlov wrote: post #14

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,…

At the risk of contributing my own probably-subtly-broken advice to the collection already present in this thread, I would note that there is a relatively sane system python3 on Catalina/Big Sur, and most projects are building and distributing compatible wheels [1] (binary packages). So something like:

    /usr/bin/python3 -m venv ./venv # create a virtual environment in ./venv
    ./venv/bin/pip install wheel # optional
    ./venv/bin/pip install dep1 dep2 dep3 ...
    ./venv/bin/python ... # up and running
is enough to get started in most cases. Of course, all bets are off for GPU or Apple Silicon support...

[1]: https://pythonwheels.com/

Re: JupyterLab 3.0

#59

Post by cat199 »

bobbylarrybobby wrote: post #42

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…

> when there are editors like VSCode that can treat ordinary python files as notebooks

was doing this in emacs before there was a jupyter notebook..

as the name implies, notebooks aren't for development, they are for interactive, shareable presentation, and presentation that also works over HTTP without needing local tooling

Re: JupyterLab 3.0

#60

Post by cat199 »

alex-treebeard wrote: post #49
bobbylarrybobby wrote: post #42

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…

> 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/

just discovered 'jupytext', which is also pretty good for this: https://jupytext.readthedocs.io/en/latest/
Post reply on HN