platform modules

[rapid ore]

I guess you have two options today:

1. dagger install the platform module and write your own local module that uses its APIs
2. dagger -m invoke the platform module so you don't have to write your own local module, but you will have to pass the source code in all the time, and pass that -m flag all the time

Between the two, #1 feels easy to suggest since it's plain old module usage, the downside being that you have to write code gluing it to your project, but to me the odds of you escaping code forever for any project are slim. Unfortunate to have to write all the boilerplate though especially if the surface area is extensive.

#2 is in an odd territory imo - you have to pass -m all the time, and pass the source dir all the time, so you wouldn't want it for local dev. I guess it's not so bad for a low-touch CI config though.

Aside from all that, yeah a real solution probably gets back to those discussions we had around toolchain modules/mixins/etc

[distant heart]

the way that I'd expect to use a platforms' team module is via the -m by sending the --app/source flag as an argument. In this flow, contextDirectory doesn't make sense as I explicitly need to set the source argument since it's the intent of the module to be generic in the first place. Similar to what I suggested here:
#general message

If the app teams are encouraged to write their Dagger modules and want to have more control over the flow, they could use #1 and use the platform module as code withing their pipelines also.

[graceful cargo]

Allowing the callee to access the caller's context directory would not make it less generic I think. It's just a design tradeoff that we had to make.

IMO the "centralized platform" use case is not resolved yet.

[ionic sleet]

Very interested in this and it's what we are planning to implement in our company. We don't know specifics yet but I'd imagine at the very minimum a config yaml (yuck) being in the caller repo with "settings". IMO currently there isn't a good way to seamlessly pass "project settings" into dagger.

There will of course be users importing and using dagger"verse" modules directly too.

[graceful cargo]

@ionic sleet do you have the same constraint as the OP in that thread, where apparently devs are not allowed to commit a dagger.json to their repo? (not sure I understand how that works)

[ionic sleet]

No, we don't. Users can commit whatever. We do want to control aspects of the pipeline centrally.

[graceful cargo]

In that case, the most reliable way is to have the app modules import central platform modules

I think that's the "Generation 1" of implementing the platform pattern with Dagger

The main tradeoff is that 1) it's incremental, the CI architecture remains the same for better or worse, 2) each app repo needs its own dagger module