#arguments not respecting decorations

1 messages · Page 1 of 1 (latest)

proven wigeon
#

Good morning! Short-time listener, first time caller ^_^ Full disclosure, I literally installed the dagger cli/sdk on Tuesday, so I am pretty new. I did look through the docs pretty couldn't find much that was super pertinent. I feel like this is a case of me not understanding something, so hopefully someone has an idea. Now that the context is set, here are the details:

I have been working on a module for go projects that leverage our internal specs/toolchain. This module is named golang (i have never been accused of being creative), which I am using to build a tiny command line app (I am essentially using that app to check my work). I decorated the parameters of my Build function accordingly, but whenever I import the module and leverage "call build --help" it does not appear to be respecting the decorations. I am suspicious that something, somewhere is caching an incorrect definition, but unsure as to where it would be.

For the purposes of testing out that theory, I made a new folder/module named gotemp, initialized it, overwrote the main.go in the gotemp module with the the one from my golang module, and finally replaced all references to golang with gotemp. After running the same build statement, I was the proud owner of what I was expecting to see from the golang module. Anyone have any thoughts? I have included screenshots to try and be as descriptive as possible.

func-gotemp-build-help.png func-golang-build-help.png func-gotemp-build.png func-golang-build.png
lapis bolt
#

Hey!

This is a bit odd but I was not able to reproduce, is there anything else in your project that uses the Golang symbol?

Here's my very simple repro

mkdir golang 
cd golang
dagger init --sdk=go

maing.go

package main

import (
    "dagger/golang/internal/dagger"
)

type Golang struct{}

func (m *Golang) Build(
    //+optional
    // path to go source code
    source *dagger.Directory,
    // +optional
    // additional flags
    args []string,
) *dagger.Container {
    return dag.Container().From("alpine:latest").WithExec([]string{"echo", args[0]})
}

dagger call build --help

...

ARGUMENTS
      --args strings       additional flags
      --source Directory   path to go source code

Can you let me know which version of Dagger you're using? Could you also rule out any projecft specific stuff by seeing if the example I shared works for you as expected?

proven wigeon
#

The version is v0.12.4, and I'm making the changes to see what happens now - thanks for the reply!

lapis bolt
#

I am not proposing you change your code to match mine, but instead make a new project somewhere from scratch to rule out any project specifc stuff that might be going on

proven wigeon
#

ohhhhh. gotcha. i was going to replace the innards of my function because i was curious. i suspect it's going to work fine given the fact that gotemp w/a swip-swapped main.go works just fine, but let me run with yours 🙂

lapis bolt
proven wigeon
#

that worked great ^_^

Screenshot_2024-08-16_at_4.07.27_PM.png
lapis bolt
#

Ok great, so now back to your project. Haha

Maybe there is a clash in symbols somewhere with the usage of Golang?

Maybe in some other dependenencies?

proven wigeon
#

So i threw the sink at this and was fine. But then I got smacked right in the face by it again (🤕), but was able to tie it to an precise action this time. This is a dagger module, and it will take me a minute to mock something up in a publicly accessible area. That said, I can textually give steps that reproduced on my end, though:

  1. Create a git repo
  2. create a golang dir in repo
  3. cd into golang repo
  4. "dagger init --sdk=go"
  5. construct main.go in a functional manner (have an optional parameter or two on the New constructor)
  6. git stage/commit
  7. "dagger -m </path/to/repo/golang> call <func>" - should be successful
  8. create a dummy function in module's main.go and save (don't commit)
  9. "dagger -m </path/to/repo/golang> call <func>" - should be successful again
  10. discard changes from git repo
  11. "dagger -m </path/to/repo/golang> call <func>" - should fail and stop respecting the decorations on the constructor

At this point it should be broken pretty disgustingly and I am unsure what the workaround/fix is besides literally throwing the kitchen sink at it.

proven wigeon
#

in the interests of disclosure, this was invoking dagger via windows context, which was using docker desktop backed by wsl2. this is likely where the issue was rooted as i couldn't reproduce from mac nor from invocation of dagger from inside the wsl environment (with repos cloned internal instead of using the windows mounts) if anyone else should ever run into this admittedly obscure one shenanigan.

stiff sierra
#

@lapis bolt actually seeemed to hit this exact same issue somehow 😛

#

but yes, what's likely happening is that the dagger file you're working with has CRLF line-endings

#

you can update the line endings to be just standard unix LF line endings, or the next patch release of dagger should have a fix for it (working on that now)

proven wigeon
#

oh thank you! that makes a ton of sense in hindsight since the execution context is linux 🤦‍♂️

stiff sierra