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

Show HN: Marimo – an open-source reactive notebook for Python

github.com

Post reply on HN
Print view View original

71–80 of 110 posts

Re: Show HN: Marimo – an open-source reactive notebook for Python

#71

Post by mscolnick »

chris_nielsen wrote: post #69

I love this, but Im using DataSpell from JetBrains at the moment because it has 2 killer features: 1. Variable viewer so I can see the current value of all variables in scope. 2. Interactive debugger Maybe the variable viewer is only important because Jupyter notebooks don’t track and rerun dependencies? So I wouldn’t need it with Marimo. But the interactive debugger is priceless. Any plan to add debugging?

1. We do have a variable viewer. We have a few helper panels in the bottom left.

2. PDB support is planned and was scoped out yesterday.

Appreciate the feedback!

Re: Show HN: Marimo – an open-source reactive notebook for Python

#72

Post by mscolnick »

bitsrat wrote: post #68

I read in a comment that Marimo is an alternate to Jupyter. Does it not depend on Jupyter Server or ipykernel ? Is it a replacement for Jupyter lab ? I am thinking of Jupyter as all the components in this diagram - https://docs.jupyter.org/en/latest/projects/architecture/con... Sorry did not get to look into the codebase yet

Correct, it does not depend on Jupyter. It’s built from the ground up with different principles in mind

Re: Show HN: Marimo – an open-source reactive notebook for Python

#73

Post by ingenieroariel »

The list of dependencies seems very short, apart from tornado it does not seem like the other ones pull in a lot of other deps.

Congrats, this looks very useful and awesome.

  dependencies = [
    # cli
    "click>=8.0,=5.10.2; python_version =0.18.0",
    # compile markdown to html
    "markdown>=3.4,=9.0,=2.13,= 0.12.0",
    # web server
    "tornado>=6.1,=4.4.0; python_version

Re: Show HN: Marimo – an open-source reactive notebook for Python

#74

Post by ShamelessC »

aidos wrote: post #25
bluish29 wrote: post #24

Earlier quoted context omitted.

There are several problems with this approach, notably you don't get information about specific platform stuff. You don't get information on how these package are installed (conda, mamba..etc). And it does not account for dependincies version conflicts which life very hard.

I don’t understand the platform thing, is that something to do with running on Windows? Why wouldn’t you just pip install? Why bring conda etc into the mix? If you have conflicts then you have to reconcile those at point of initial install - pip deals with that for you. I’ve never had a situation in 15 years of Python packages where there wasn’t a working combination of versions. These are genuine questions btw. I se…

Yes, there are more problems with Windows.

Re: Show HN: Marimo – an open-source reactive notebook for Python

#75

Post by ShamelessC »

bmitc wrote: post #66
aidos wrote: post #20

Earlier quoted context omitted.

People always complain about pip and python packaging but it’s never been an issue for me. I create a requirements.base.txt that has the versions of things I want installed. I then: pip freeze -r requirements.base.txt > requirements.txt Install is then simply: pip install -r requirements.txt Updating / installing something new is a matter of adding to the base file and then refreezing.

Poetry handles all of this properly.

Just not PyTorch apparently.

Re: Show HN: Marimo – an open-source reactive notebook for Python

#77

Post by chris_nielsen »

mscolnick wrote: post #71
chris_nielsen wrote: post #69

I love this, but Im using DataSpell from JetBrains at the moment because it has 2 killer features: 1. Variable viewer so I can see the current value of all variables in scope. 2. Interactive debugger Maybe the variable viewer is only important because Jupyter notebooks don’t track and rerun dependencies? So I wouldn’t need it with Marimo. But the interactive debugger is priceless. Any plan to add debugging?

1. We do have a variable viewer. We have a few helper panels in the bottom left. 2. PDB support is planned and was scoped out yesterday. Appreciate the feedback!

That's awesome, ok I'm going to go check it out. Great work!

Re: Show HN: Marimo – an open-source reactive notebook for Python

#78

Post by nnx »

Very interesting project, a breeze of fresh air and welcome competition to Jupyter.

I guess it's still very early but the onboarding for Mario VSCode is not great at the moment, no idea how to actually start writing a Marimo notebook (no "Create: New Marimo notebook" option like Jupyter's).

Then I then tried clone the cookbook repo, and get "module not found" errors that are even less friendly than when it happens on Jupyter: have to figure out which cell the error actually comes from to even know which module is missing.

Re: Show HN: Marimo – an open-source reactive notebook for Python

#79

Post by hedgehog »

smacke wrote: post #39
akshayka wrote: post #19

Earlier quoted context omitted.

We've thought briefly about cell-level caching; or at least it's a topic that's come up a couple times now with our users. Perhaps we could add it as a configuration option, at the granularity of individual cells. Our users have found that `functools.cache` goes a long way. We also let users disable cells (and their descendants), which can be useful if you're iterating on a cell that's close to the root of your noteb…

ipyflow has a %%memoize magic which looks quite similar to %%xetmemo (just without specifying the inputs / outputs explicitly): https://github.com/ipyflow/ipyflow/?tab=readme-ov-file#memoi... Would be cool if we could come up with a standard that works across notebooks / libraries!

Function-level caching is the best match for how I'd use it. Often the reason for bothering to cache is that the underlying process is slow, so some kind of future-with-progress wrapper could also be interesting. An example of how that could be used would be wrapping a file transfer so the cell can show progress and then when the result is ready unwrap the value for use in other cells. Or another example would be training in PyTorch, yield progress or stats during the run and then the final run data when complete.

Re: Show HN: Marimo – an open-source reactive notebook for Python

#80

Post by YousefED »

simonw wrote: post #67
LoulouMonkey wrote: post #58

Earlier quoted context omitted.

Hi Simon, slightly unrelated question. I'm a big fan of your work, and as I've learnt a lot from reading your blog posts over the years, I'd be curious to know a bit more about typical use cases for wanting to work with Observable notebooks. The only reason why I'm using A JavaScript notebook tool (Starboard.gg) is to be able to access cool visualisation packages like Anychart or Highcharts. Given the hype around Obs…

I primarily use Observable to build interactive tools, as opposed to Jupyter which I use more for exploratory development and analysis. Here are some of my Observable notebooks which illustrate the kind of things I use it for: https://observablehq.com/@simonw/search-for-faucets-with-cli... https://observablehq.com/@simonw/openai-clip-in-a-browser Those are both from https://simonwillison.net/2023/Oct/23/embeddings/ h…

Congrats OP on launching this, looking forward to dive further in! It's great to see people experimenting in the Reactive + Live Programming space as like you mention, I think it can bring a lot of improvements to how we build software. Did you run into any limitations adopting this model?

> A killer feature of Observable notebooks for me is that they provide the shortest possible route from having an idea to having a public URL with a tool that I can bookmark and use later

Thanks for sharing simon! I'm working on an Open Source Notion + Observable combination (https://www.typecell.org), where documents seamlessly mix with code, and can mix with an AI layer (e.g.: https://twitter.com/YousefED/status/1710210240929538447)

The code you write is pure Typescript (instead of sth custom like ObservableJS) which opens more paths to interoperability (aside from having a public URL). For example, I'm now working to make the code instantly exportable so you can mix it directly into existing codebases (or deploy on your own hosting / Vercel / whatever you prefer).

Post reply on HN