#Env redeclared

1 messages · Page 1 of 1 (latest)

charred pagoda
#

I'm getting this error with 0.18.2:

Error: failed to serve module: input: moduleSource.asModule failed to load dependencies as modules: failed to load module dependencies: select: failed to load dependencies as modules: failed to load module dependencies: select: failed to call module "docker" to get functions: call constructor: process "go build -ldflags -s -w -o /runtime ." did not complete successfully: exit code: 1

Stderr:
# main
./dagger.gen.go:348:6: Env redeclared in this block
        ./compose.go:29:6: other declaration of Env
final vector
ebon sparrow
#

I fear that it may be a naming conflict introduced by our new Env core type? Is that possible @split plinth @void crag ?

charred pagoda
#

I have done nothing but update from 0.17.x

ebon sparrow
#

@charred pagoda do you have a type called Env in your own module?

charred pagoda
split plinth
#

hm neither of those declares an env

#

but the error seems to be coming from a module called docker

split plinth
#

but hm, i would have thought this might be possible. i suspect that if you update the engineVersion in your dagger.json (using dagger develop), then this might actually work

#

^ actually ignore, you'd have to update the docker module

ebon sparrow
#

@charred pagoda I can update that upstream module, then you can update the dependency and that should fix it

charred pagoda
#

Would using namespaces avoid this?

ebon sparrow
#

Well normally types should be namespaced so I'm not sure I understand why this conflict happens

#

ah I remember something specific about the Go SDK maybe? @jed do you remember what triggers it?

split plinth
#

before we moved all the types into dagger.

#

to preserve compatibility, for super old dagger versions we keep aliases for them at the top-level

charred pagoda
#

That sounds like something to deprecate at some point.

split plinth
#

it is deprecated yup

#

it's actually removed - it's only provided to old modules that haven't been updated

#

there is a fix we can do though, i'll write up an issue

ebon sparrow
#

@split plinth can you explain how that deprecated feature causes the Env conflict?

split plinth
#

yes 🙂 gimme a moment, soz 😛
i started writing an issue, realized we had an actual bug in similar code

ebon sparrow
#

ooh it's the docker module itself that has an old engine dep? and therefore is getting the toplevel alias which causes the conflict?

#

but I'm surprised that our own modules would have that old of an engine dep, seems unlikely

split plinth
#

there's not even an engineVersion in there, it's that old

#

(which means we infer v0.11? i think? essentially, it's pre-module compat at all)

ebon sparrow
#

Oh I see, I thought it was a module on our own repo

#

I'll update it

#

@charred pagoda can you show the parts of your code where you use that docker module?

split plinth
ebon sparrow
#

Ah

split plinth
ebon sparrow
#

@split plinth I updated the docker module (not pushed yet) but get this error when loading it:

Error: input: failed to get schema: failed to get schema for module "docker": type "Env" is already defined by module "daggercore"
ebon sparrow
split plinth
#

yeahhhh i would expect that to work 🤔

ebon sparrow
#

I tried renaming to EnvVariable but that's taken too 😭

final vector
#

Environment should be fine

ebon sparrow
#

This is a bug though right? Types should be namespaced, but it appears that they are not

#

cc @uneven grove @slow sail

split plinth
#

dependency types are definitely namespaced. i suspect that your own types aren't getting namespaced 🤔

#

does seem like a bug to me though

#

i don't know why we wouldn't do that

ebon sparrow
#

Well that error seems explicit and intentional. It's a dagger error saying "hey you are not allowed to have a name of the same type"

# 
        if ok {
            // NB: this is defense-in-depth to prevent SDKs or some other future
            // component from allowing modules to extend external objects.
            return fmt.Errorf("type %q is already defined by module %q",
                objDef.Name,
                modType.SourceMod().Name())
        }
#

old code

#

So I guess core types have always clashed with module types

split plinth
#

mm, this did used to be a thing - but we then did start namespacing in go (which was one of the reasons to not allow this in the first place)

#

looking now

#

ah

#

so we actually try and namespace Env when we do it - but this check then fails (because it's from a core dep, so we don't actually namespace it)

#

if you have a type that's not in core, like EnvFoo, then it is correctly namespaced

#

so this is definitely a bug

#

i think the reasoning is because of how the api works - but there might be an easy-ish fix here?

#

will issue this too, i have no time left today 🙏

split plinth
charred pagoda
#

Will this be fixed in 0.18.3?

split plinth
charred pagoda
split plinth
#

I'm considering this a bug - I'm doing some work atm around improvements to backwards compat, I'm hoping that this will easily be resolved by that

#

but it's still in investigation right now, so sorry, that's why I can't give a good answer right now

#

if you subscribe to the issue linked above, you should be able to get updates - I'll try and remember to update this thread as well

wraith marten
#

Hi, we've come across this issue as well when trying to use dagger 0.18 (we've got a dependency on testcontainer)
I understand there's no fix nor workaround atm ?