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

131–140 of 145 posts

Re: JupyterLab 3.0

#131

Post by Jugurtha »

klelatti wrote: post #129
ktpsns wrote: post #128

Earlier quoted context omitted.

Jup, MS Colab is one of the many commercial Jupyter/IPython notebooks available. There are also Y-combinator startups like https://deepnote.com/ I hope that these closed source commercial platforms give back something to the open source community around Jupyter once they get out of the red numbers.

Indeed and they all use their own notebook interface which are (in my view) inferior or at least no better than JupyterLab. I get that they feel the need to add their own features (collaboration etc) to distinguish themselves but it would be so much better if they had settled on a single UI.

We do use JupyterLab for the notebook experience on https://iko.ai. I had a chat with one of the core members of the project using real-time-collaboration when they were trying iko.ai. We chatted on the notebook itself.

What I explained was that in our experience of many years doing paid machine learning projects for large enterprise, we never thought to ourselves: "Darn, if only Jupyter[Lab] had better stylesheets, this project would go so much faster." It has never happened. When we started building our platform, we were not in the position of front-end devs trying to make a better notebook, we were in the position of a company with deliverables for yesterday, and we naturally started solving for actual problems doing machine learning for real clients, as opposed to finding windmills to fight.

In our experience, projects are slow not for lack of better stylesheets or animations. Therefore, we ignored that and focused on removing frustrations we had in the real world: long-running notebook scheduling, automatic experiment tracking for parameters, metrics, models, and code. Model deployment and monitoring. Real-time editing.

That's why I don't really follow news about "jupyter-killers". I kept an eye out of curiosity, but every time one pops out, they solved things that don't matter much, or claimed they solved hidden state until you read the article and found they're caching results or something like that.

Re: JupyterLab 3.0

#132

Post by Jugurtha »

nojito wrote: post #78
ajford wrote: post #50

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

Netflix does and it’s absolutely horrifying. https://netflixtechblog.com/notebook-innovation-591ee3221233 https://netflixtechblog.com/scheduling-notebooks-348e6c14cfd...

Not Netflix, but we do use notebooks on our internal platform. Long-running notebooks for model training, but you can view their state as they run even after you close the tab or get disconnected from the internet.

We also publish AppBooks, which are automatically parametrized notebooks. However, we automatically detect and track experiments, and then we deploy models in the form of an endpoint to be invoked by consumers, with a convenience page for humans to invoke the code by sending JSON data, or uploading a CSV file.

- https://iko.ai/docs/notebook/

- https://iko.ai/docs/appbook/

Re: JupyterLab 3.0

#133

Post by Jugurtha »

abdullahkhalids wrote: post #54
bobbylarrybobby wrote: post #51

Earlier quoted context omitted.

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.

Exactly. When you want to show results to a client, for example.

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

We wanted to let others execute the code without being overwhelmed by the code, but we also wanted our colleagues not to write an application or parametrize the notebook by adding metadata or tagging cells, so we added a feature named AppBooks[0]. We automatically detect parameters you want to expose, build a form on top of your notebook, and then serve a clean page.

The user gets a page with a form with fields corresponding to your parameters, they just change the values and hit Run. The notebook runs with the new parameters and the client/stakeholder gets the result.

This solves the problem of: "I have a notebook, how do I not only show my work, but allow domain experts to tinker and run this with specific values". Especially useful when the parameters are pretty domain specific (like instrumentation for nuclear power plants where the client wants to try the model on edge values).

These runs are tracked in case you want to share a training AppBook where it produces a better model, for example.

- https://iko.ai/docs/appbook

Re: JupyterLab 3.0

#134

Post by mikecoles »

ben509 wrote: post #101
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,…

> I don't think it's Python's fault. Well, there's a long legacy of half-baked solutions and kludges. And, especially, install instructions consistently suggest you do the worst thing: install stuff using pip. Everyone knows that's bad advice, because it always fails in mysterious ways, and there's no good way to roll everything back. I recommend: python3 -m pip install pipx # Don't rely on the pip3 bin. pipx install…

Interesting coincidence: I'm currently side-watching a Youtube video about poetry.

The video discusses python packaging in general. You have to skip through several minutes of pre-roll though. https://www.youtube.com/watch?v=tNlurLxcf68&feature=emb_logo

Re: JupyterLab 3.0

#135

Post by specialist »

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

Had same experience.

Hoping to help clear some backlog, I tried to help with some ML & data pipeline house cleaning. Had never used Python before, but how hard could it be? OMG. One really doesn't appreciate ease and simplicity of multiple simultaneous JDK installs, all peacefully coexisting, until working on some python and nodejs projects.

Just running user space dev env via Docker was recently front paged here on HN. I believe that will become the norm.

Being a macOS user, I looked to see if there was something more lightweight. Like maybe a port of podman. Lighter than running a virtual Linux instance.

Again as a macOS user, I feel like I'm overdue to embrace the remote dev desktop set up. I've read that Googlers don't do any work locally; they all remote shell into servers running the tool stack. So very X Windows; what is old is new again.

Re: JupyterLab 3.0

#136

Post by specialist »

ben509 wrote: post #101
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,…

> I don't think it's Python's fault. Well, there's a long legacy of half-baked solutions and kludges. And, especially, install instructions consistently suggest you do the worst thing: install stuff using pip. Everyone knows that's bad advice, because it always fails in mysterious ways, and there's no good way to roll everything back. I recommend: python3 -m pip install pipx # Don't rely on the pip3 bin. pipx install…

As someone who has done driveby python work, how would I even know how to do that? Noob me found all sorts of howtos and getting started guides. Seemingly contradictory, mutual exclusive.

My (extended) team couldn't even get all the Pythonistas to agree on The One True Python Stack™.

Re: JupyterLab 3.0

#137

Post by klelatti »

Jugurtha wrote: post #131
klelatti wrote: post #129

Earlier quoted context omitted.

Indeed and they all use their own notebook interface which are (in my view) inferior or at least no better than JupyterLab. I get that they feel the need to add their own features (collaboration etc) to distinguish themselves but it would be so much better if they had settled on a single UI.

We do use JupyterLab for the notebook experience on https://iko.ai . I had a chat with one of the core members of the project using real-time-collaboration when they were trying iko.ai. We chatted on the notebook itself. What I explained was that in our experience of many years doing paid machine learning projects for large enterprise, we never thought to ourselves: "Darn, if only Jupyter[Lab] had better stylesheets,…

Thanks - I've just signed up for an account and it looks really good! I'll say hello on Slack in a moment.

We've been working on a JupyterLab based product for the insurance industry - not machine learning but shares a lot of the features - e.g. possibly long running models etc. Trying to land our first (fairly large) customer at the moment!

Can you share any more on what your plans are especially from a business perspective?

Re: JupyterLab 3.0

#138

Post by disgruntledphd2 »

specialist wrote: post #136
ben509 wrote: post #101

Earlier quoted context omitted.

> I don't think it's Python's fault. Well, there's a long legacy of half-baked solutions and kludges. And, especially, install instructions consistently suggest you do the worst thing: install stuff using pip. Everyone knows that's bad advice, because it always fails in mysterious ways, and there's no good way to roll everything back. I recommend: python3 -m pip install pipx # Don't rely on the pip3 bin. pipx install…

As someone who has done driveby python work, how would I even know how to do that? Noob me found all sorts of howtos and getting started guides. Seemingly contradictory, mutual exclusive. My (extended) team couldn't even get all the Pythonistas to agree on The One True Python Stack™.

You don't. It's a total nightmare for newbies.

I ended up putting off learning Python for years as this kind of stuff kept happening (first the 2/3 transition, and then massive pip breakage).

Re: JupyterLab 3.0

#139

Post by jtpx »

laichzeit0 wrote: post #116
eggie5 wrote: post #98

anyone still like classic notebooks better???

Yes! Every now and then I give JupyterLab a go but I keep going back to classic notebook. The only two extensions I need is Vim key bindings and Black formatting. I might checkout version 3 in a few months, but classic has a “feel” that just works for me. I’ve also tried the VSCode abs PyCharm notebooks. The dealbreaker is always how it displays the output of cells. It sucks compared to classic.

Then you might be interested in a new project called JupyterLab Classic, an alternative JupyterLab distribution with the Classic Notebook look and feel: https://github.com/jtpio/jupyterlab-classic

Once the vim and black extensions adopt the new extension distribution system, they should also be compatible with JupyterLab Classic.

Re: JupyterLab 3.0

#140

Post by sangnoir »

coldtea wrote: post #64
sangnoir wrote: post #52

Earlier quoted context omitted.

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

> followed by random annoyances that remind you you are using inferior, non-GNU utilities: Well, you can switch to another ls in 10 seconds by "brew install gnutools" or some such. Not to mention the same arguments could be made for FreeBSD, commercial unices, etc. Come to think of it, I've been using Unix (including Linux) for 25 years, and never even occured to me to expect "ls my_dir -l" to work.

> Well, you can switch to another ls in 10 seconds by "brew install gnutools" or some such.

I did - but I never remember to type "gls" instead of "ls" - if I were that mindful, I'd always put in the flags at the start, where the BSD utils expect them. As sibling comment noted, trailing flags usually happens when I run a command and decide to amend the flags by up-arrowing and typing. A typical result is "ls -al my_dir -tr" when I realize I want to sort by mod date, post-facto.

I've been using GNU utils 95% of the time I've used Unix(-like) systems: I expect "ls -al my_dir -tr" to work: it's 2021 - recognizing flags isn't rocket science.

Post reply on HN