#Was just fixing this and adding a test

1 messages · Page 1 of 1 (latest)

heady shell
glad goblet
#

yes, I can try to repro. When I did it, I had a subfolder by the same name of the module. I wonder if that mattered

#

yes confirmed.

mkdir daggertest
cd daggertest
mkdir mymodule
dagger mod init -m mymodule
#

oh but i didn't use the --name flag

#

ok it fails with the --name flag.
I guess the issue is dagger mod init -m mymodule works without a name or a sdk. Maybe that's intended? But confusing for sure

heady shell
# glad goblet ok it fails with the `--name` flag. I guess the issue is `dagger mod init -m my...

I guess the issue is dagger mod init -m mymodule works without a name or a sdk. Maybe that's intended? But confusing for sure
Yes that actually is intended, but confusing in the current state due to us not having documented its utility.

The idea is you can:

  • dagger init, which results in an empty module
  • then do e.g. dagger install github.com/foo/daggerverse/coolmod@v0.0.1
  • then you can invoke dependencies directly with a short name like dagger call -m coolmod cool-func
  • then if you want to start writing actual module code that uses those dependencies, you will be able to do dagger develop --sdk go --name mymod to give the module a name+sdk (but that command hasn't been merged yet)
glad goblet
#

If dagger init has a -m flag, should it fail if --name and --sdk is missing?

I understand the utility of dagger init but if I'm creating an empty module, I'd expect to already be inside the root/module folder

#

I may be coming at this from a "converting a module that has a root in dagger.json" standpoint and not a creating a new module structure standpoint. I can see the benefit of being able to dagger init -m mymodule and have that create the folders etc.

heady shell
glad goblet