marimo 0.6.14 no longer imports xdsl without error about marimo HOT 14 CLOSED

Ok I've found a way to reproduce this online: when I import from our framework in multiple places, it gives weird errors, that are due to the __annotations__ being mixed up. I'm not sure whether we're doing something wrong in xdsl itself, but the error is not visible when running in any environment other than marimo 0.6.14 and up. Here's a notebook with the behaviour:

https://marimo.app/l/kf3rz4

from marimo.

It must just be because runtime checkable has side-effects. We'll use a different check on our side -- no need to change your library code. Will let you know when a fix is released.

from marimo.

@superlopuh , we just released version 0.7.3 with a fix. If you're still having problems, please re-open this issue.

Thanks again for reporting!

from marimo.

Just in case it helps debug something, the error is there because the subclass has in its annotations, the __annotations__ of a superclass, while not having the corresponding field in its __dict__, and the code that checks for consistencies for each of these fails when traversing the mro()

from marimo.

I mistook the failure to import as a minimal reproducible example of my bug, but that's not quite correct. I have an issue with a local notebook, and I'm still trying to figure out exactly what the error is, but it's not the one I described above. I'll close this issue for now, sorry about the noise.

from marimo.

@superlopuh , thanks for opening the issue. I took a look at the commits in 0.6.14 and couldn't figure out what could have caused this :/

from marimo.

I wonder if it's one of the dependencies updated in the release? b055329
The Pyodide update seems like the most likely cause, maybe there was a change in the import functionality in the major version bump.

from marimo.

I don't think it's related to Pyodide. I can reproduce your issue locally (and your code works in the Pyodide REPL).

From your example, importing Add first, then Attribute works; but doing the imports in the opposite order fails.

I think this is a bug in marimo; I'm just not sure what specifically about your package causes it to surface.

from marimo.

This is the "weird error" I see:

@superlopuh , you mentioned that __annotations__ get mixed up. Can you give any more insight or clues into what might be going wrong? I'd like to try and fix this for you.

from marimo.

I think I've narrowed down the issue. We inspect attributes of variables in memory after running a cell (in an attempt to find dataframes), and it looks like xdsl doesn't like that.

from marimo.

Calling the following function on xdsl.ir.Attribute ends up breaking subsequent xdsl imports:

https://github.com/marimo-team/marimo/blob/main/marimo/_plugins/ui/_impl/tables/types.py#L16-L25

In particular, it's the isinstance check against the runtime_checkable protocol that breaks things. Any idea why that would be? (Edit: could be related to this CPython issue, which was supposed to be resolved in Python 3.12+ -- however, I can repro the xdsl issue in marimo using Python 3.12)

Two options for fixing this:

1. Maybe this is a bug on your end? I don't know enough about how xdsl is implemented to know. It does seem surprising that an isinstance check interferes with imports.
2. We could be more explicit in checking for dataframe-ness of an object, by just doing a bunch of isinstance checks against known types, without using runtime_checkable

from marimo.

Am I understanding correctly that removing this check makes the error go away? It does seem similar to the issue you linked. It's always possible that the bug is on our end, but it's curious that it's only ever reproducable in this marimo scenario. If runtime_checkable is known to have issues with supported versions of Python, then maybe it would be worth trying a different way to perform the check?

from marimo.

Amazing, thank you!

from marimo.

Amazing, thank you!

from marimo.