Module Versioning Conundrum

[loud flower]

(pre-emptively creating thread)

Asking because there's some extremely wide ranging implications to putting objects from other modules in the type signatures of functions+fields. In the interest of time I'm checking to see how kickable-down-the-road this can is 😄

[tawny finch]

I read PR comments too, yes this could have wide implications.

I'm interested in both of the scenarios but we could narrow it down to a safer approach.

let me think an example

Ideally, I would have a type called Step and different modules would wrap this module as an implementation like actions/setup-go or trufflesecurity/trufflehog.

What I really want to chain this 3rd party steps together. This can be doable with a return type or a input argument.

[loud flower]

Okay so to double check I'm on the same page, you want users to be able to write something like:

func (m *Mod) FooStep(...) *Step { ... }

Where Step is an object defined in your gale module that they are depending on?

[tawny finch]

@loud flower if you're free now wanna jump of dev-audio and post summary here later to speed things up

[loud flower]

Sure thing, I'll be there in 1 min

[tawny finch]

As we talked in #911305510882513037, I'm sending a small summary here,

Currently, we're generating modules based on Custom Action in github like: https://github.com/aweris/gale/blob/d00c71c68eb7abf9a34131cf87f84a9643825e72/daggerverse/gha/trufflesecurity/trufflehog/main.go#L9-L54

As the next step I would like to create a DX similar to the snippet I shared below and having a chaining operations using/depending other than core types

dag.Gale().
  Builder().
  WithStep(dag.SetupGo().Step).
  WithStep(dag.Trufflehog().Step). 
  Build(). // This creates our workflow
  Run()    // This starts the workflow

SetupGo, and Trugglehog would be separate modules that shared a common dependency + version together with gale to access the same object information

☝️ this is how I imagine how chaining would look like not really hard dependency

[loud flower]

Thanks again Ali 🙏 I posted another comment on the PR summarizing my updated thoughts: https://github.com/dagger/dagger/pull/6102#issuecomment-1813475256

[pale bough]

Just glanced through your last comment - think it makes sense 🙂
I would say that the way to actually do 1 and remove other module args/returns would be to add some additional checks - theres not actually really any functionality to remove, it's just kind of all a consequence of making module types idable

[loud flower]

From my last reading of the code i think we need to also just make sure the schema of transitive deps don’t show up in the schema of a module you depend on, but I’ll double check that with a test case