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

91–100 of 110 posts

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

#91

Post by graemep »

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…

Problems 1 and 2 can be solved by using a virtualev/venv per project.

3 is solved by the workflow of manually adding requirements and not including dependencies. It may not work for everyone. Something like pipreqs might work for many people.

I do not understand why 4 is such a problem. Can you explain further?

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

#92

Post by aldanor »

dimatura wrote: post #22

I already use jupytext to store notebooks as code but the improved state management and notebook-as-app features are pretty compelling and I'm trying it out. Unfortunately, I'm quite used to very specific vim keybindings in Jupyter ( https://github.com/lambdalisue/jupyter-vim-binding ) that make it pretty hard to use anything else :/

If you're a vimmer and a jupyter user, do yourself a favour and switch from browser to vscode: vim emulation is much better overall and you get proper python lsp experience, with jumping to definitions, type inference, copilot, and all that.

(Neovim user myself, as much as I dislike vscode for everything else, as of now it's hard to replace it when using jupyter)

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

#93

Post by actuallyalys »

aidos wrote: post #20
akshayka wrote: post #10

Earlier quoted context omitted.

Yes, the second half of reproducibility is for sure packages. A solution for reproducible environments is on our roadmap ( https://marimo-team.notion.site/The-marimo-roadmap-e5460b9f2... ), but we haven't quite figured it out yet. It's a bit challenging because Python has so many different solutions for package management. If you have any ideas we'd love to hear them.

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.

The post you’re responding to said that there are many Python packaging options, not that they don’t work. Pip freeze works reasonably well for a lot of situations but that doesn’t necessarily mean it’s the best option for their notebook tool, especially if they want to attract users who are used to conda.

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

#94

Post by petters »

Defining the same variable more than once is an error. The reason for this is obvious. But if the variable is never used in a cell that does not first write to it, reusing variable name should be possible.

Allowing that would be good, because many notebook cells start with "fig, ax = plt.subplots(2, 2)" and this is currently not allowed more than once.

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

#95

Post by jkl5xx »

petters wrote: post #94

Defining the same variable more than once is an error. The reason for this is obvious. But if the variable is never used in a cell that does not first write to it, reusing variable name should be possible. Allowing that would be good, because many notebook cells start with "fig, ax = plt.subplots(2, 2)" and this is currently not allowed more than once.

Does the local underscore variables feature solve this? Or the approach outlined in the plots tutorial? IMO, not allowing redeclaration is more valuable than supporting this use case. A slight paradigm shift away from your example gives you the significant benefits of a reactive environment with fewer edge cases/quirks. I'd much rather have a notebook error out instead of silently overwriting a value. You save so much time debugging.

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

#96

Post by pastorhudson »

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.

This is my workflow too. And it works fine. I think the disconnect here is that I grew up fighting dependencies when compiling other programs from source on Linux. I know how painful it can be and I’ve accepted the pain and when I came to python/venv I thought “This isn’t so bad!”

But if someone is coming from data science and not dev-ops then no matter how much we say “all you have to do”. The response will be why do I have to do any of this?

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

#97

Post by n8henrie »

aidos wrote: post #20
akshayka wrote: post #10

Earlier quoted context omitted.

Yes, the second half of reproducibility is for sure packages. A solution for reproducible environments is on our roadmap ( https://marimo-team.notion.site/The-marimo-roadmap-e5460b9f2... ), but we haven't quite figured it out yet. It's a bit challenging because Python has so many different solutions for package management. If you have any ideas we'd love to hear them.

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.

I follow a similar approach -- top-level dependencies in pyproject.toml and then a pip freeze to get a reproducible set for applications. I know there are edge cases but this has worked really well for me for a decade without much churn in my process (other than migrating from setup.py to setup.cfg to pyproject.toml).

After trying to migrate everything to pipenv and then getting burned, I went back to this and can't imagine I'll use another third-party packaging project (other than nix) for the foreseeable future.

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

#100

Post by bluish29 »

jkl5xx wrote: post #95
petters wrote: post #94

Defining the same variable more than once is an error. The reason for this is obvious. But if the variable is never used in a cell that does not first write to it, reusing variable name should be possible. Allowing that would be good, because many notebook cells start with "fig, ax = plt.subplots(2, 2)" and this is currently not allowed more than once.

Does the local underscore variables feature solve this? Or the approach outlined in the plots tutorial? IMO, not allowing redeclaration is more valuable than supporting this use case. A slight paradigm shift away from your example gives you the significant benefits of a reactive environment with fewer edge cases/quirks. I'd much rather have a notebook error out instead of silently overwriting a value. You save so muc…

> Does the local underscore variables feature solve this

I tried this yesterday trying to convert a Jupyter notebook with a log of fig, axs, and it was very annoying converting all of them. I tried local _ with fig_ and ax1_ …etc. but it is considered a variable that cannot be reused too. Furthermore, I expected local vs global variables to be cell based somehow, but that was naive on my part. It does static analysis, not dynamic, so defining something like _suffix and add it to all reused variables and assign different values for each cell will need a dynamical analysis to work.

Post reply on HN