so for some reason i thought that it was

[abstract river]

Looks like you need the dot .

dagger -m github.com/sagikazarmark/daggerverse/go@v0.9.0 -c '. --version 1.24.3 | container'

In that module , version is a constructor arg.

Doesn't work without the dot. Now of course, that one is optional. Gotta try with required, but I think it's the same thing, just without naming the param since it uses positionals for requireds.

[fringe ledge]

but i'm not sure that would change the default instantiation? like if you do . --source=../dagger-worktree-copy; test ... the . instantiation is no longer in scope when you call test i don't think?

[abstract river]

oh, where'd that semicolon come from 😆 not familiar with that invocation style

[fringe ledge]

just the equivalent to a line break in interactive mode?

[abstract river]

Seems buggy!

dagger -m github.com/sagikazarmark/daggerverse/go@v0.9.0
. --version 1.24.3 | container | terminal # try: go version => 1.24.3 ✅
. --version 1.21 | container | terminal   # try: go version => 1.21.13 ✅
. --version 1.21 ; container | terminal   # try: go version => 1.24.3 ❌

[proper kelp]

Dot points to the module loaded in current context but you can reference other modules, just use the path to them instead of .. If you want to save on repeating the constructor args, you can set a var with the args.

[proper kelp]

In the last one, when you use the semicolon you're basically defaulting to the default args for the constructor. They don't get saved after first use.

[abstract river]

yep just realized that I got the default latest

So should someone use the semilcolon at all? I don't see a good reason to use if you have any constructor args, likely to no do what you want.

dagger -m github.com/sagikazarmark/daggerverse/go@v0.9.0
⋈ . --version 1.21 ; --version 1.22 | container | terminal ❌
# first succeeds ; second fails since no leading module ref
Go@xxh3:b9e1ddb3d4c37326
! find module "--version": input: moduleSource local path "--version" does not
! exist

⋈ . --version 1.21 ; . --version 1.22 | container | terminal ✅

[proper kelp]

Yep, if the expectation is that the constructor args are preserved, it doesn't work like that.

Just . --version 1.21 doesn't do anything.

[abstract river]

I mean today, these two work:

. --version 1.21 ; container | terminal 
. --version 1.21 ; . --version 1.22 | container | terminal

so it's a little odd that if you want to use constructor args, you must have the module ref (bottom one)

whereas if you don't, you don't need the module ref (top one)

[proper kelp]

Would you rather always require the constructor name/path when calling module functions even if no required arguments?

[abstract river]

Once a module is loaded, you kinda assume you're in that context
so the . (dot) could seem slightly superfluous, but in case there are required/positional constructor args, I can see those "could" clash with a function name, so you need a way to "fence off" the constructor portion. Given all of the constraints, it's an elegant solution to allow . in place of the full module ref.

I wonder if some terminal interactivity/hints could help people.
Or a "training wheels" mode that would help people to learn the syntax that they'd turn off.

Not sure if/where people are stumbling today. It's actually comforting that the semicolon just means separate commands and that they don't share anything across the boundary.

[fringe ledge]

This convo went so far off the rails while I was on a call XD— my original question was intended to be fairly orthogonal to ‘.’ , but about providing a way to change module constructor args on shell startup…

Like right now modules get default constructed if they can be— what if I want to change how they get default constructed? What if a module is not default constructible but I want to provide an arg so that it can be default constructed?

[proper kelp]

Not sure what you mean. It's like in an SDK where you do dag.Go().Container(). The shell just has a convenience where you can exclude the constructor, so it's just container instead of go | container. Right off the hackaton where the Shell came out, we had .config which would save the constructor arguments for later. Is this what you want? Later on it became .load and then .use, but we ended up simplifying by tying module loading to filesystem navigation.

[fringe ledge]

yes, .config would be along the lines of what i'm talking about. i don't know the history of .load or .use. am i understanding correctly that none of this functionality remains in the shell impl today? tying module loading to filesystem navigation makes sense, but doesn't fix the UX problem of "i want to provide a constuctor argument to the module implied by my CWD"

[proper kelp]

Our current solution to that is setting a var. Same as you would do in an SDK.

[fringe ledge]

like a shell var? or a module var?

[proper kelp]

Shell var

Or shell function

[fringe ledge]

so like my_module=$(. --source=../whatever)? or like source=../whatever; .?

[proper kelp]

The first one.

[fringe ledge]

or via the partial .env support that sneaks around for secrets https://github.com/dagger/dagger/discussions/10401#discussioncomment-13147184

really i'll just XY myself here: i'm trying to make sure we have consistent support for reloading host directories in the contexts where users pass host directories to persistent sessions. i thought there was gonna be some way to do that on the command line that starts dagger shell, but it seems like maybe there's not and we don't want there to be

[proper kelp]

go_124=$(go --version 1.24.3)
go_121=$(go --version 1.21)

$go_124 | container | terminal
$go_121 | container | terminal

Or

go_124 { go --version 1.24.3); }
go_121 { go --version 1.21); }

go_124 | container | terminal
go_121 | container | terminal

[fringe ledge]

yeah i understand you can do all these things in scripts, it's just surprising to me that we don't support those things being done at shell startup

[proper kelp]

Because the initial context is just the one you start with, but we also want to support the same thing with dependencies or other modules that have been loaded through .cd or just direct reference. Those are the cases where .config didn't fit well.

[abstract river]

https://tenor.com/view/haitian-haiti-own-goal-goalkeeper-arquero-gif-23440795
I "helped"

[fringe ledge]

the example being given is difficult because container exists on the core api... what i'm trying to point out is that PWD=~/src/dagger dagger-dev | test and test invoke the same thing, but what i'm trying to clarify is that if i want to change how dagger-dev is constructed for the plain test invocation, I cannot do that, i can only actually construct the thing explicitly and then | test

[proper kelp]

I don't see a problem with that. What we have is more similar to SDKs, and easy to reason. You're talking about a convenience. Would it make it easier to understand and intuitive to use?

Seems like just the convenience to exclude the constructor if all you need is default values in the constructor is confusing.

If you changed the constructor for test, would you expect all other top-level functions to use the same constructor? Or do you imagine each top-level could have different constructor values?

The former is what we had with .config but didn't scale to other cases not the current (default) module.

To be clear, there's been mentions of maybe bringing back something like we had with .use. I understand the appeal. We just need to think/discuss the design to see if we can actually improve rather than make it worse.

It's been difficult trying to come up with a simple paradigm that's consistent and unifying.