#Updated from 0.9.4 -> 0.96: "Error: unsupported list of lists for flag" in python module

1 messages · Page 1 of 1 (latest)

robust ibex
#

Glanced through the 0.9.5 and 0.9.6 release notes for both the Python and Engine releases and can't see anything that would impact supported types.

Example:

@object_type
class ThisIsAMod:
    this_is_now_broken: list[list[str]] | None = None
    
    @function
    def set_that_variable(self):
        self.this_is_now_broken = [["list","one"],["list","two"]]
        return self

Have I missed something in the update notes?

#

Downgrading to 0.9.4 is strangely not working either, if that helps resolve this

dull estuary
#

@robust ibex is this in the context of dagger modules?

robust ibex
#

Yes

dull estuary
#

you sure you didn't change anything in your code which made it stop working?

robust ibex
#

So I'm now wondering if I hadn't updated the SDK previously, or even what version I demonstrated this on, because I've got a recording of this working 😕

#

I'll reduce it to a list of strings, it's demonstration code (not production code) so not important, thanks @dull estuary

dull estuary
#

cc @glossy oar maybe you know something about this?

glossy oar
#

@robust ibex So, did this work at some point?

#

Fyi, the release notes haven't included anything about modules since it's a hidden and experimental feature.

#

I'm investigating.

#

The error doesn't come from Python, it comes from the CLI, added very early on, in october (since v0.9.1).

dull estuary
glossy oar
#

Yeah, possible. I just mean it's been there since the beginning of the current iteration of CLI, from september/october. It's not a technical limitation, just didn't know how to present it so left it for another time.

#

Weird thing is that it's failing when creating a flag, meaning a function input, when you have it on a field.

#

Oh, scratch that. It's the constructor.

#

Which tells me that this error for you started after adding constructor support.

#

That means, started in v0.9.4.

robust ibex
#

I thought I'd demonstrated on 0.9.4 but that may not be the case

#

My Dagger version was 0.9.4 when I started updating modules today, I may have updated it previously and forgotten

#

I've got the module working by making it list[str] which is still sufficient to demonstrate the module

glossy oar
#

Should probably have a way to not expose the constructor. If you have fields, a constructor is created automatically, and exposed to the API.

robust ibex
#

By constructor do you mean the create function that we can now define?

glossy oar
#

And could also allow a list of lists as input, but what would that look like in the CLI?

glossy oar
#

That could be use as a workaround to disable __init__ now that I think of it. If you add a create method without arguments.

robust ibex
#

I'd not considered how inputting a list of lists would work on the CLI 😅. In this case it's a var: list[list[str]] | None = None and just set to e.g. [["words", "words"], ["words", "words"]] during execution

glossy oar
#

Wait, you're not using field() so that shouldn't be exposed to the CLI anyway. I need to look further.

#

Ah, I think the field isn't exposed but the constructor with that field is. That's subtle. Didn't even think of that before.

robust ibex
#

Yeah it's not exposed to the user with --help currently

glossy oar
#

You should be able to exclude the field from the constructor with:

from dataclasses import field as datafield
from dagger import function, object_type


@object_type
class Test:
    foo: list[list[str]] | None = datafield(default=None, init=False)

    @function
    def bar(self):
        self.foo = [["list","one"],["list","two"]]
        return self
#

To expose the field to the API but not in the constructor, it would be dagger.field instead of dataclasses.field.

robust ibex
#

That's helpful, I'll give that a go, thanks!