private modules

[turbid matrix]

Definitely an interesting case to think about. I suppose the alternative would be to just make them regular Go packages within the module, but that's hard because all the types live in package main. Is that right?

[trim forge]

Definitely an interesting case to think about. I suppose the alternative would be to just make them regular Go packages within the module
that make sense but than we would lose the dagger.gen.go in the package

that's kinda blocker for it

[turbid matrix]

right right

Maybe that could be put into a separate package instead? 🤔 cc @ember talon (this has come up before, just connecting dots)

Alternatively we could have a notion of a "private module" - it'd be a module like any other, but it could declare its intent to not be a publicly supported API ("private": true in dagger.json or something)

[trim forge]

this makes also sense

maybe we can extend this topic to what do we want to publish and when do we want to publish to daggerverse?

The way I see daggerverse is replacement for my github releases. The place I shared my stable releases with the users as part of my development cycle

[turbid matrix]

Agreed - I think that'd be its only purpose for now, maybe more things later but the main point would be for Daggerverse to ignore it. Though, we might still want caching properties when we implement that.

Maybe "private": true could just mean it's unlisted? You could still browse to it (and it'd say it's private or some such), there'd still be the global caching properties, it just wouldn't be featured so prominently

[frank crescent]

what about private functions within the module? That’s what I do. Separating out modules if I don’t want anyone else to find them, feels like overkill, but maybe it depends on the situation