#Contextual modules & loading modules

1 messages · Page 1 of 1 (latest)

quasi badger
#

Thanks! Continuing to scratch this itch if you don't mind...

#

I'm still wondering about this edge case in the "contextual modules" proposal:

  • dagger call -m github.com/shykes/daggerverse/hello: which module to load?
  • Option 1: github.com/shykes/daggerverse/hello (the standalone module at the target address)
  • Option 2: github.com/shykes/daggerverse/hello/.dagger (the contextual module attached to the target address)
  • Option 3: it's an error

There's a good argument for either. Which is my problem. What if that means there is no good answer, because our current semantic for "loading a module" mixes 2 different use cases? What if what we really want it to split "load a module" in 2 distinct operations? A rabbit hole I don't particularly want to go down 😭

#

cc @pseudo tiger @tender fog @steady bobcat @vague shoal

tender fog
#

I'm not sure if it's really a case that needs to be handled, we can just make it an error to have both a standalone module and contextual module that overlap like that

#

(also getting back on your ping in the GH issue for all this, which is related I guess)

quasi badger
#

The problem with making it an error, is that it would break a legitimate use case: using Dagger to develop a standalone Dagger module (ie. "CI for my CI")

#

In fact that would be the litmus test for when to make a standalone module: if it feels like a software project of its own, that needs a CI of its own: that's when you know it's time to move it out of .dagger and make it standalone. We would enforce this by forbidding nested .dagger

tender fog
#

Right but I think generally speaking all the "CI for my CI" tasks should be supported via built-in features, independent of contextual modules. So if you want to right tests for your module, there should be a way to do that without having to make an entirely separate module just to run tests (I bring up tests in particular since that's an existing feature request separate from contextual modules)

quasi badger
#

But what if contextual modules are that feature?

#

They seem to be the perfect fit - if we ship contextual modules as proposed, and don't use it for that purpose, wouldn't it be weird?

#

It's definitely a pattern already, that people create sub-modules with names like dev or tests for that purpose

#

(I am one of those people 😛 but I know @minor arch does it too)

#

If I turn out to be wrong and it's possible & good to disable this use of contextual modules, that would definitely solve this dilemma.

tender fog
#

If I were to write tests for my module, I would want to do something simple like, e.g. for the Go SDK, put a main_test.go file next to my module's implementation and just write the tests there. If the instructions were to make a whole other module that's contextual I think I would be confused (in the shoes of someone unfamiliar with any of this)

#

AFAICT the only corner case is specifically a contextual module overlapping with a standalone module that's also in the root of the repo, so even assuming that there are cases where that's strongly needed, the worst case scenario I think is that you just put your standalone module not in the root of the repo. Personally, that sounds okay to me.

#

Another possibility is to relax the constraint of a contextual module needing to be in .dagger in the root of the repo, which is what I'm getting at here: https://github.com/dagger/dagger/issues/7199#issuecomment-2109004701 Specifically, just don't force that constraint (even if it's a reasonable default and/or best practice), then we have more leeway to support corner cases like the one here

quasi badger
#

will catchup on this tonight! 🙏

minor arch
#

I think at some point I was proposing using dagger.json to mark the module, presence of .dagger to decide if it's contextual or not. That essentially makes an overlap between contextual and standalone module impossible which is desirable IMO.

Personally, I would find it really confusing if I had such an overlap locally. ie, what happens when I run dagger call/develop in the root? What if I'm inside .dagger?

Regardless of what makes a module a module, I don't think allowing an overlap is desirable.

I'm still a bit reluctant to accept the .dagger directory pattern: I do like creating test submodules which would certainly be contextual, leading to a tree like this:

mymodule
├── dagger.json
└── tests
    └── .dagger
        ├── dagger.json
        └── main.go

I still find that a bit weird.

quasi badger
#

@minor arch the tree would rather be:

mymodule
├── dagger.json
└── .dagger
    └── dagger.json
    └── main.go
minor arch
quasi badger
#

(except separating dev & tests module, that's not needed when daggerizing regular projects so IMO same situation if your project itself is a module

minor arch
#

fair