#Can you make sure there's a flag to opt-

1 messages · Page 1 of 1 (latest)

lofty sluice
#

this is not as easy as I though since IIUC, the "flag" will have to be also within dagger.json so whenever the engine does the code generation for the module, it needs to be know if it's ok to re-use the project's go.mod (if present) and adjust accordingly.

cc @void patrol does that seem right?

void patrol
#

Possibly yes, but I'll double check some details. On a conceptual level, ideally the engine should only ever try to create a go.mod during dagger init (unless configured not to via this flag) and every other time after that just use the regular go logic of "go.mod from current dir or above".

But not sure if our current codegen logic cooperates with that idea yet or if it'll always try creating a go.mod if it can't find one. Checking

lofty sluice
#

so dagger develop, will also re-generate the go.mod I assume

void patrol
#

Right so I guess a possible approach here would be to distinguish dagger init (where there's not already a dagger.json) and only in that case ever possibly try to create a go.mod. Which I think is doable with some minor plumbing.

#

I'm just seeing if we can avoid putting this in dagger.json, that's definitely viable as a fallback but nice to avoid pollution if possible

lofty sluice
#

so the author can decide to re-use their parent go.mod files or not

void patrol
# lofty sluice but I'm not sure if we can escape this. Imagine I push a module and I forget to ...

My hot take is that if you forget to include the go.mod and push w/out it and then there's no go.mod to be found loading, that should just be an error (and would be already). It's true we could attempt to handle that by storing this in dagger.json, but it doesn't seem worth it to me. Like if the user makes a mistake along those lines, I'd rather just tell them via an error than try to do something magical to handle it. It's just easier to explain and understand

Not 100% decided, but that could if nothing else be a starting place behavior.

#

I think the plumbing could be something like:

  1. We know whether or not dagger.json existed already here: https://github.com/sipsma/dagger/blob/d9a15262229f1dba0aa53dbd0216908438331995/core/schema/module.go#L1073-L1073
  2. Which could be plumbed through to codegen invocations here: https://github.com/sipsma/dagger/blob/d9a15262229f1dba0aa53dbd0216908438331995/core/schema/module.go#L754-L754
  3. and then used to determine whether or not we should ever try to init a go.mod (only try if dagger.json didn't exist already and not told to re-use the parent)
#

To be super clear, this is just drive-by thinking out loud, the devil may be in all the details, so take all this with salt

lofty sluice
#

dagger develop is currently addressing that 🤔

#

and again, without something in the dagger.json, we wouldn't know if we should re-use the parent's go.mod unless we manually supply a flag which I assume we don't want for dagger develop

void patrol
#

The thing is, if you delete go.mod on accident and want it back, either:

  1. You have it in git history already because you're working on a module that was initialized previously
  2. You literally just dagger init'd it and it's not already in git history, in which case yeah you'd have to re-init the module to get it back, unless dagger develop covers this. But since you just did a dagger init that doesn't seem like a lot of overhead.

So yeah if we put this in dagger.json we'd be handling that one extra case. IMO it doesn't feel like the tradeoff is worth it there in terms of needing to figure out how/where to fit this into dagger.json, but just my opinion. If we did add it to dagger.json in some sort of SDK-specific configuration section, I wouldn't be opposed to it or anything. Just questioning if it's worth it yet

#

I'm sure we'd find many more use cases in the long run for an "sdk-specific configuration" section of dagger.json, it just opens up questions around version compat, how SDKs define the specific configuration they support, etc.

lofty sluice
# void patrol The thing is, if you delete go.mod on accident and want it back, either: 1. You ...

I agree with you also that I'd much prefer avoiding the dagger.json change since it's not fully clear that we need this here.

My biggest concern is that we'd break dagger develop given that it currently re-generates the go.mod and go.sum and we won't be doing that anymore. At the same time, I also think (along with users) the current go.mod generation UX is broken as it's currently impossible to "not" re-use the paren'ts go.mod if the project has one

#

so maybe it's not that much big of a deal

void patrol
#

Yeah I do think this is a minorly breaking change no matter what. So changing the behavior around what happens if a user accidentally rm's go.mod and doesn't have it in git history doesn't make the situation any worse overall

lofty sluice