#All modules in .dagger?

1 messages · Page 1 of 1 (latest)

umbral laurel
#

One obvious downside is that it would be a breaking change for existing modules (but could have a long deprecation period)

wanton panther
#

Yeah I'm double guessing that idea

#

The goal was to just remove a concept -- modules are modules, they're in .dagger, that's it. Contextual vs standalone is not a thing, the only net new concept is calling .Context()

#

But I didn't really consider the drawbacks

umbral laurel
#

You could argue that a lot of the modules in daggerverse, are still packaging third-party software

wanton panther
#

(and .Context() would also work for standalone -- it's just THEIR context)

umbral laurel
#

So maybe "contextual" and "reusable" are not incompatible

wanton panther
#

hmmm. #dagger.Source flashbacks

umbral laurel
#

Well we have that already - dag.CurrentModule().Source()

wanton panther
#

does that work for contextual modules? (.dagger aside)

umbral laurel
#

But here we're talking about inverting it I guess. Dagger files inside, instead of outside

umbral laurel
wanton panther
#

dag.CurrentModule().Source() --> inside .dagger, dagger.Context() --> parent of .dagger ?

umbral laurel
#

In the current proposal:

  • currentModule().source() -> the directory with the source code for the module's functions. (main.go, go.sum)
  • client().context() -> the directory containing .dagger, if it exists
wanton panther
umbral laurel
#

In other words: "what if all Dagger modules were fundamentally contextual, because you're always daggerizing something: either your software project, or someone else's"

#

But at the same time, I don't want to have to fork Nginx to make a nginx module

#

Even though I am wrapping the nginx source code. I just want to do it dynamically in my code - not statically in my git repo

wanton panther
umbral laurel
wanton panther
#

yeah, probably easier to Git() their stuff

umbral laurel
#

And Dagger does it so well at runtime

#

BUT it's interesting to look at this, because it's not so clear cut. ie. Yes I want to "git() their stuff", but I also want to pin which version of their stuff, and Dagger doesn't support that super well yet

wanton panther
#

One other advantage of .dagger is cohesion: if for instance we do decide to support e.g. version pinning in the future (the thing we're not doing well right now), we could store that data in .dagger/version.lock

#

always having .dagger makes it consistent

umbral laurel
#

in that particular case, wouldn't dagger.json be a better place?

wanton panther
#

that being said, <module directory>/version.lock vs .dagger/version.lock is not that hard of a concept

umbral laurel
#

But yeah I agree, we're bound to need to store something that doesn't fit well in dagger.json

#

If that's the idea - make .dagger a generic "storage area" for different subsystems of Dagger, then we should consider namespacing it more cleanly, and using that namespacing for SDKs

#

ie. the Python SDK would get .dagger/python, the Go SDK would get .dagger/go, and they do whatever they want in their respective directories

#

Otherwise, there is bound to be conflicts between what you suggest (Dagger manages this directory on behalf of different subsystems, eg. versioning), and what SDKs do today (manage the same directory for their own needs, possibly generating or wiping files)

wanton panther
#

e.g. would be nice to have goreleaser/goreleaser/.dagger

#

today the pattern would be goreleaser/daggerverse/goreleaser which is not bad either

umbral laurel
#

mmm, so best practice for a reusable module would be: 1) fork the upstream, 2) add a dagger module, 3) open PR.

#

Then either your fork is the module; or if the PR is accepted, upstream becomes the module

wanton panther
#

playing devil's advocate

umbral laurel
wanton panther
#

"forked from goreleaser/goreleaser, 123 commits behind" is not a good look for a repo

umbral laurel
#

Yeah. It makes sense if there's a good chance that it will be merged

#

It's a pretty different view of the world - but I find it very interesting

wanton panther
#

but you could always make a "standalone" module with no contextual source, just a .dagger for things that may not get merged (e.g. nginx)

umbral laurel
#

In this version, everything is very aligned: you're truly "daggerizing the world"

#

either daggerizing your own project, or daggerizing an upstream project - but always daggerizing

wanton panther
#

what about conflicting usage though?

#

goreleaser standalone build and contextual build might do VERY different things

#

like, build goreleaser vs use goreleaser to build my project

umbral laurel
#

The main difference is how you get the source code

umbral laurel
#

makes me think of "dev dependencies" in traditional package managers

#

It's true we've discussed using .dagger for 2 different purposes:

  1. Define a "dev dependency" for the context project ("use this module to develop goreleaser")
  2. Wrap a software project into a dagger module ("use this module to use goreleaser")
#

This feels very important, and also very difficult to make a decision 😅

umbral laurel
#

Quick snapshot of my thought experiment, before I forget 🙂 For future discussion.

  • Modules are always contextual. Their directory is always called .dagger.
  • To daggerize a project, create a module at .dagger in the project directory. This is done with dagger init.
  • The entire contents of the module are in .dagger, including .dagger/dagger.json. To un-daggerize a directory, remove .dagger and you are done.
  • A dagger module can itself be daggerized! So you can create a module to help develop your module. That module will be in .dagger/.dagger
  • The directory containing a module is called its context directory. A module can read and write to its context directory.

Comparison: .git

umbral laurel