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

41–50 of 110 posts

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

#41

Post by aidos »

bluish29 wrote: post #32
aidos wrote: post #25

Earlier quoted context omitted.

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…

I will try to summarize the complaints (mine at least) in obvious simple points 1- pip freeze will miss packages not installed by pip (i.e. Conda). 2- It does include all packages, even not used in the project. 3- It just dumps all packages, their dependencies and sub-dependencies. Even without conflicts, if you happen to change a package, then it is very hard to keep track of dependencies and sub-dependencies that n…

Ok. I think that’s all handled by my workflow, but it does involve taking responsibility for requirements files.

If I want to install something, I pip install and then add the explicit version to the base. I can then freeze the current state to requirements to lock in all the sub dependencies.

It’s a bit manual (though you only need a couple of cli commands) but it’s simple and robust.

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

#43

Post by bluish29 »

aidos wrote: post #41
bluish29 wrote: post #32

Earlier quoted context omitted.

I will try to summarize the complaints (mine at least) in obvious simple points 1- pip freeze will miss packages not installed by pip (i.e. Conda). 2- It does include all packages, even not used in the project. 3- It just dumps all packages, their dependencies and sub-dependencies. Even without conflicts, if you happen to change a package, then it is very hard to keep track of dependencies and sub-dependencies that n…

Ok. I think that’s all handled by my workflow, but it does involve taking responsibility for requirements files. If I want to install something, I pip install and then add the explicit version to the base. I can then freeze the current state to requirements to lock in all the sub dependencies. It’s a bit manual (though you only need a couple of cli commands) but it’s simple and robust.

I don't think that manual handling of requirement.txt in a collaborative environment is a robust process. It will be a waste of time and resources to handle it like that. And I don't know about your workflow but it is obviously not standard and it does not address the first and forth points.

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

#44

Post by aidos »

bluish29 wrote: post #43
aidos wrote: post #41

Earlier quoted context omitted.

Ok. I think that’s all handled by my workflow, but it does involve taking responsibility for requirements files. If I want to install something, I pip install and then add the explicit version to the base. I can then freeze the current state to requirements to lock in all the sub dependencies. It’s a bit manual (though you only need a couple of cli commands) but it’s simple and robust.

I don't think that manual handling of requirement.txt in a collaborative environment is a robust process. It will be a waste of time and resources to handle it like that. And I don't know about your workflow but it is obviously not standard and it does not address the first and forth points.

Haha. Ok. I think that’s where we’re just going to have to agree to disagree.

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

#45

Post by mscolnick »

esafak wrote: post #34

Could this be used with MDX or something to embed interactive examples in documentation? That is an underserved use case.

It is not possible at the moment (we use iframes in our documentation), but once we support WASM, it should be possible.

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

#48

Post by Micoloth »

Wow.. Really great work, finally someone is doing it!

Since I've thought about this for a long time (I've actually even made a very simplified version last year [1]), I want to contribute a few thoughts:

- cool that you have a Vscode extension, but I was a little disappointed that it opens a full browser view instead of using the existing, good Notebook interface of Vscode. (I get you want to show the whole Frontend- But I'd love to be able to run the Reactive Kernel within the full Vscode ecosystem.. Included Github Copilot is cool, but that's not all)

- As other comments said, if you want to go for reproducibility, the part about Package Management is very important. And it's also mostly solved, with Poetry etc...

- If you want to go for easy deployment of the NB code to Production, another very cool feature would be to extract (as a script) all the code needed to produce a given cell of output! This should be very easy since you already have the DAG.. It actually even existed at some point in VSCode Python extension, then they removed it

Again, great job

[1] https://github.com/micoloth/vscode-reactive-jupyter

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

#49

Post by akshayka »

krawczstef wrote: post #46

how do you read the resulting python files? That's what I'm struggling with -- but I guess the point is you don't read them, you use marimo for that?

Thanks for the question. Each cell is represented as a function that maps its referenced variables to the variables it defines. Cells are sorted in the order they appear on the notebook page.

If you run `marimo tutorial fileformat`, that'll open a tutorial notebook that explains the fileformat in some detail.

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

#50

Post by yowlingcat »

This is very cool. I think I need to play around with this a bit more to wrap my head around the reactivity element, but the basic shift of ipynb to standard Python would be such a huge workflow improvement for my team. We use jupyter notebooks when prototyping and trying to code review unwieldy python-in-JSON is miserable. Great to see an alternative that's worked its way around that.
Post reply on HN