JupyterLab 3.0 • Hacker News Board

Re: JupyterLab 3.0

#101

Post by ben509 » Wed, Jan 06, 2021, 2:16 AM UTC

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 jupyterlab
    # Now jupyter has an independent virtualenv.
    # To install dependencies:
    pipx inject jupyterlab numpy
    # Where is everything?
    pipx list
    venvs are in /Users/ben/.local/pipx/venvs
    apps are exposed on your $PATH at /Users/ben/.local/bin
    ...

Once you've done that, never install anything directly with pip3 again. If you're working on a project, use pipx to install poetry / dephell / pipenv and use them to manage the virtualenv.

And you can get rid of it all:

    pipx uninstall-all
    python3 -m pip uninstall pipx

Re: JupyterLab 3.0

#102

Post by ohazi » Wed, Jan 06, 2021, 2:25 AM UTC

coldtea wrote: post #63

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

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

I think it's more inertia than any of these things.

The entire point of this thread is that (a) is false -- see grandparent and the xkcd joke. It's not easy. It pretends to be easy, but is usually broken in some crazy way instead. Apt is also easy, but it actually works more often than not.

(c) was relevant in 2006, when the novelty of OS X was that it was a UNIX that you could actually use as a daily driver. This is what initially got developers to move to Mac. But it's been fifteen years, and all jokes aside, the "year of the Linux desktop" for developers was probably around 2012. Linux may still have issues, but they're not worse than the hoops you have to jump through to make today's macOS behave.

Trendy tech companies are still buying macbook pros for their employees because that's what's been trendy for the last decade, not because they actually ask new hires what they prefer. Practical tech companies do, and at places like that you usually see a mix of macs and thinkpads.

Re: JupyterLab 3.0

#103

Post by auxym » Wed, Jan 06, 2021, 2:27 AM UTC

bitanarch wrote: post #22

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

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

Note that you now have to pay for a commercial anaconda license if you're using it for anything that isn't education or hobbyist stuff.

https://www.anaconda.com/blog/anaconda-commercial-edition-fa...

Re: JupyterLab 3.0

#104

Post by baldfat » Wed, Jan 06, 2021, 2:31 AM UTC

auchtopus wrote: post #80

baldfat wrote: post #37

Earlier quoted context omitted.

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.

What do you enjoy about racket? I used it for a semester in college, and it was next to unbearable. I can appreciate it as a fun little functional programming gimmick, but nothing more than that.

I just love Lisp and you pretty much have a fun small language you can fit in my small brain with Racket. The biggest issue is the libraries. Everyone writes their own specific libraries for their problems, because its easy and fun.

I could have done it in Python but portability was always the issue.

At my former job I had to make charts from pictures with English and Spanish lettering. Took me 30 minutes to have a working client that got installed in a dozen computers that afternoon.

I needed to also re-structure the companies file system for every computer in our company.

Personally I worked in audio video contract work from time to time and I was able to make a dozen short cut programs that actually saved my biscuit several times. I could have done it in python but the portability kicked my butt. Racket made executables super easy.

Also I went through How to Design Programs and I learned a ton.

Re: JupyterLab 3.0

#105

Post by hcrisp » Wed, Jan 06, 2021, 2:50 AM UTC

auxym wrote: post #103

bitanarch wrote: post #22

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

Note that you now have to pay for a commercial anaconda license if you're using it for anything that isn't education or hobbyist stuff. https://www.anaconda.com/blog/anaconda-commercial-edition-fa...

I don't think that is true if you install miniconda.

https://docs.conda.io/en/latest/miniconda.html

Re: JupyterLab 3.0

#106

Post by ImaCake » Wed, Jan 06, 2021, 3:10 AM UTC

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…

I use conda to do effectively the same thing. If my conda environment breaks and I can't roll it back, at least I can destroy it and start again.

As an aside; it is really hard to explain why you should use anything but pip3 to people who only rarely need to interact with python.

Re: JupyterLab 3.0

#107

Post by ImaCake » Wed, Jan 06, 2021, 3:16 AM UTC

ohazi wrote: post #102

coldtea wrote: post #63

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

I think it's more inertia than any of these things. The entire point of this thread is that (a) is false -- see grandparent and the xkcd joke. It's not easy. It pretends to be easy, but is usually broken in some crazy way instead. Apt is also easy, but it actually works more often than not. (c) was relevant in 2006, when the novelty of OS X was that it was a UNIX that you could actually use as a daily driver. This is…

>was relevant in 2006, when the novelty of OS X was that it was a UNIX that you could actually use as a daily driver. This is what initially got developers to move to Mac. But it's been fifteen years

My anecdata for this is that I bought a MacBook in 2020 for precisely this reason. I am not a programmer, mostly my use case is bioinformatics and processing large datasets. Native terminal is better than WSL (although WSL is good now) and macOS is much more reliable than linux ever has been for me.

Re: JupyterLab 3.0

#108

Post by tourdownunder » Wed, Jan 06, 2021, 3:18 AM UTC

kbelder wrote: post #17

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?

jupyterhub addresses some of these concerns.

Re: JupyterLab 3.0

#109

Post by mynameisash » Wed, Jan 06, 2021, 3:23 AM UTC

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

My most recent professional project involves - among other things - a Python API deployed to AKS. I'd used Python here and there for fun and on the periphery of work, but this was the first time I had to dive into it full-on.

While I know it has earned its praise for good reason -- as I'm sure all the data scientists I work with would attest to -- as an engineer, Python has been really frustrating to work with.

Re: JupyterLab 3.0

#110

Post by ben509 » Wed, Jan 06, 2021, 3:48 AM UTC

narush wrote: post #99

I'm one of those extension developers that working on getting my extension working on JupyterLab 3.0 :-) I've been developing Mito ( https://trymito.io ), a spreadsheet extension to JupyterLab that allows you to edit a spreadsheet in a notebook as if you're editing Excel. You edit the spreadsheet, and Python code gets generated that corresponds to your edits. Feedback on the above greatly appreciated. And congrats on…

I'll have to try that next time I'm struggling with pandas.

One thing to look into is figuring out some logic of cancellation to clean up the generated code. Even if you just checked back one step it would mean less Foo_Bar['D'] = 0.

I think saving the analyses in the home directory is defeating the purpose. One appeal of a notebook is that you can break all the steps out and show them to someone, add commentary, etc.

I'd want to use it interactively to figure out how to get my data looking the way I want, and then show off how the analysis works by pulling out non-interactive Step widgets that visualize changes into their own cells.

That said, I'm often doing stuff with numpy so I need the notebook to document exactly what the dimensions mean, why I did a "clever" thing, etc.

Also, as long as "import mitosheet" is hitting your analytics APIs, it's going to set off alarm bells if we try to use it inside our VPN. The compliance people are not likely to look at what it's sending or why, they'll just ban it and move on.