#Weird Elixir SDK loading regression šŸ§µ

1 messages Ā· Page 1 of 1 (latest)

wind frost
last inlet
#

squint i might've hit this earlier running engine generate but got past it by rebasing onto @pseudo anvil's merge-main'd llm branch

unreal birch
#

I just upgraded v0.16.2->v0.16.3 and hit the same thing... looking into it

wind frost
#

completely unconfirmed gut feeling that this is related to the disappearance of source field in dagger.json?

#

in case you're curious, yes I'm doing all these by hand šŸ˜›

#

but very very happy that I can trust our build to be repeatable! even when it's failing repeatably

#

also being able to stack builds

last inlet
#

in my shell history i hit it on v1.16.2 as well, the first thing i tried was brew upgrade, bringing me to v1.16.3, then i rebased my branch onto the newest llm and it worked

wind frost
#

to repro:

  • load github.com/dagger/dagger -> will fail with elixir erros
  • load github.com/dagger/dagger/sdk/elixir/dev -> will load a boilerplate module with 2 template functions from dagger init (no idea why)
unreal birch
#

Yeah I mean the fact that v0.16.3 at least works on main is the most important, at least we have that...

But this specifically is the PR that is required to fix the error: https://github.com/dagger/dagger/pull/9852

Looking through it for why

#

Oh yeah based on the message here this was expected by Justin I guess https://github.com/jedevc/dagger/commit/3ec42f15204da2bfc0c4636f952fe36584fc4e6e

And probably a reference to https://github.com/dagger/dagger/pull/9727

GitHub
chore: update elixir dev module with breaking change Ā· jedevc/dagge...

Signed-off-by: Justin Chadwell

GitHub
feat(sdk/elixir): improve Elixir project structure by wingyplus Ā· P...

Closes #8609
In this changeset, I modify the Elixir module project structure by moving the Elixir application to the root of the module. So the structure is looks like:
$ ls -lah
total 56
drwxr-xr-...

#

So yeah I guess it was just a breaking change to elixir module layout, which means v0.16.3 engines need the latest changes on main

unreal birch
# wind frost to repro: - load `github.com/dagger/dagger` -> will fail with elixir erros - lo...

load github.com/dagger/dagger/sdk/elixir/dev -> will load a boilerplate module with 2 template functions from dagger init (no idea why)
I think this specifically happens because v0.16.3 engine elixir sees a module source w/ no actual functions and then just generates the default ones created on init.

I guess other SDKs do that too, e.g.

sipsma@dagger_dev:~/repo/github.com/sipsma/dagger$ dagger init --sdk=go --name=test /tmp/testmod
...
Initialized module test in /tmp/testmod
sipsma@dagger_dev:~/repo/github.com/sipsma/dagger$ rm -rf /tmp/testmod/{main.go,dagger.gen.go,internal}
sipsma@dagger_dev:~/repo/github.com/sipsma/dagger$ dagger call -m /tmp/testmod --help
āœ” connect 0.3s
āœ” load module 0.5s
āœ” parsing command line arguments 0.0s

Call one or more functions, interconnected into a pipeline

USAGE
  dagger call [options] <function>

FUNCTIONS
  container-echo   Returns a container that echoes whatever string argument is provided
  grep-dir         Returns lines that match a pattern in the files of the provided Directory

Which makes sense in terms of the implementation details, but surprising from an end-user perspective

wind frost
#

I don't understand the nature of the breaking change, is it a change to how elixir sdk loads source? and I guess sdk/elixir/dev itself uses the elixir sdk?

#

but if that's the case why not also change sdk/elixir/dev in the same commit

unreal birch
# wind frost I don't understand the nature of the breaking change, is it a change to how elix...

sdk/elixir/dev itself uses the elixir sdk?
Yes, exactly, and since dagger-dev depends on it, we needed these updates

is it a change to how elixir sdk loads source
my understanding is it's a change to layout of module source code, so elixir looks in a different place for the actual source code of functions than it used to

but if that's the case why not also change sdk/elixir/dev in the same commit
it's tricky because we bootstrap dev engines w/ a stable engine, so CI needs to work on the stable engine

#

Actually, I am sort of confused how our dev tests never hit this, since they 1. bootstrap a dev engine using stable engine 2. run our ci using the dev engine

wind frost
#

am I understanding correctly that this would be avoided if engine compat also applied to which version of builtin sdks you get?

unreal birch
unreal birch
unreal birch
#

Yeah unless I'm missing something (entirely possible) it seems like those dev jobs were not actually running against the dev engine? Attempting a fix here but have to test in GHA šŸ˜¢ https://github.com/dagger/dagger/pull/9853

pseudo anvil
#

back from dinner

#

now im surprised i was able to skip by this hardship so quickly lol. ran into it after upgrading to v0.16.3 => assumed it was a release thing, so merged the PR into main => hack/dev on main was fine => merged main into llm, was fine => merged llm into llm-multi-obj, was fine

unreal birch
unreal birch
unreal birch
#

Got it to use the dev CLI finally, but still hitting stable engine

Also looked through history and based on GHA log output believe this changed ~3 weeks ago here, so at least it hasn't been that long

wind frost