#passing structs between modules

1 messages · Page 1 of 1 (latest)

lofty wyvern
#

@zenith wing @mild vale I've been thinking about this one again 😛

the original logic in https://github.com/dagger/dagger/pull/6102#issuecomment-1813209934 still makes sense to me, but the issue with our conclusion is that passing types around is really confusing - you have to declare an interface to it, just for this purpose, the dx of that is hard, it's not in all languages (though we can fix these)

#

i remember when we talked about this originally, the issue is that we might end up generating schemas that have more than one version of an object in it - e.g. foo's Bar object might have entirely different fields, or might even be a Enum in one, and an object in another!

#

but, a lot of these use cases i've seen are for wanting to split up a module into two - and the author has control over both

potentially - could we version every module type? (e.g. at it's most basic adding the version of the module to it's name when we namespace types?)

that way, you don't have the conflicting issue (Bar-1.0 isn't the same type as Bar-1.1, so you can't pass them like that). but we do unblock being able to accept/return that type, with the new restriction that if you do this, the caller must use the same version of the module as the callee

#

or maybe, each module can expose a list of pinned dependencies - you can only accept/return types from deps that are pinned, and when you install a pinned dep, all callers are required to use that same version (if they don't, they panic) - this also solves some of the most common cases, while not solving it entirely generically.

zenith wing
#

Trying to namespace the objects (by version like you said or alternatively "import path") is something that I ruled out then because I think it would devolve very quickly into extreme mess + confusion. I think pinned sounds like basically just exposing the dependency hell problems we'd like to avoid.

I think that interfaces will be more ergonomic once we have self call support. Many of the weirdness+gaps with them currently are the same fundamental problems we will fix via self calls.

Other vague ideas (not mutually exclusive with anything else or each other):

  1. If you could "extend" a module rather than just add it as a dependency, then you would inherently be able to expose all of its types in args/return values. Basically start out with a different module's types+implementation and just add more to it.
  2. (extra vague and probably breaking changes across all SDKs) if all our autogenerated types were more like interfaces (duck typed with multiple possible implementations backing them), then maybe custom interfaces would be less "different" and easier to use overall
zenith wing
#

Re-reading, I might have misunderstood what you were saying around pinned. It sounds like the same sort of area as "extending" a module potentially? Not exact same idea but kind of close?

lofty wyvern
#

Yeahhh, it's kind of like extending, but I guess I was imagining you could extend multiple modules

#

I agree it does cause some big issues with streaming weird module issues into the ecosystem - but maybe it's okay - it's only applied if you actually consume those types from those modules

#

But it does mean it spreads kinda virus like, which not everyone would be careful with

#

Maybe improved interface semantics are just what I want - but it does still feel annoying to have to declare an interface just to pass around an internal type between internal modules

#

Maybe we could allow if only for local modules 🤔 since they're all the same "version" conceptually

zenith wing
#

Definitely something there, still muddy in my head though

lofty wyvern
#

maybe i want a "utils module"? i.e. a module that can only be imported via a local path, but can't be installed via git - this is pretty much an "extension" like you talked about earlier