#Radical thought of the day: we should

1 messages · Page 1 of 1 (latest)

sweet hill
#

Maybe dagger develop should return a Directory by default, instead of exporting back to the context directory by default

sweet hill
#

@primal ridge I'm curious of your thoughts on this

#

It just feels like a messy corner of our DX

#

eg. find . -type f -name "dagger.json" -execdir sh -c 'dagger develop' \;

primal ridge
#

I like it in theory but I’m not sure whether in practice it would save effort overall or just trade it off for other problems.

Is the main issue with the linting just needing to have the generated code locally and up to date still?

primal ridge
sweet hill
#

It feels like a two-headed problem:

  • The "native" DX for codegen (dagger develop) does not work great with native tools, there are various edge cases
  • The daggerized DX for codegen (Directory.asModule().ContextDirectory()) is also not great.

So it feels like we're doing a meh job on both sides, and I wonder if we just committed to one side, we could make it awesome, and then just say "you must use Dagger to develop for Dagger"

#

I don't know how to put it exactly, it feels like we're missing an opportunity to make a module's dev pipelines a shining example of the ultimate daggerized dev pipeline

primal ridge
#

I feel like if we give users standard dagger development containers/services, then we still need to integrate with their IDEs (either running the IDE in the dev container or using that protocol vscode has for remote environments, etc.), so while it would be nice to have a more controlled environment, I don't know yet if it actually eliminates all the paper/larger cuts we're hitting.

#

In terms of codegen, I think there's plenty of prior art out there, we are far from the only tool that relies on generated code being available. It could be worth seeing if we are missing something everything else is doing that makes it more seamless? (vague thought admittedly'f

#

None of this is to say we shouldn't provide dev environments. There's only one hill to climb that I'm aware of, which is the source code syncing issue, but we already have ideas on how to approach that.

#

Maybe it would make sense to do that just in the context of dagger develop (e.g. dagger develop --interactive ?), get it as good as we can and then if it's just obviously better than the current experience, make it the best practice?

#

thinking out loud

sweet hill
#

Yes we need to integrate with IDEs, but we could standardize on an integration that involves the IDE running containerized tools via dagger

#

Which is a very valuable and desired integration anyway. So would be useful dogfooding

sweet hill
#

Sorry that's not a very structured thought

#

Another perspective is that it's difficult for Dagger to both 1) be perfectly managed by the native host platform (ie. go), AND at the same time 2) perfectly manage the same platform

#
  • Go tooling sees a bunch of go files, expects them to comply with normal rules of go files at all times
  • Dagger expects to be in control of which go files go where, which are generated when and how
#

But maybe I'm overthinking it. There's definitely been a lot of papercuts. Maybe we just go through the list, fix them, and all will be fine

primal ridge
# sweet hill I think the problem is that we combine 1) codegen, and 2) our ecosystem with mod...

Right, go.mod/project.toml/package.json/etc. type issues are harder and I'm less aware of as much prior art as there is with codegen per-se, I think what we're doing is relatively more unique. It's very much a situation of millions of little details to get right and each one we miss is another papercut. Go, python and node/bun/etc. are all well known disasters of varying degrees in terms of the complexity and constantly shifting best practices in this whole area.

#

But I also don't know how to avoid them entirely either. Even if we have standardized dev environments we still need to contend with the complexity, just in a more controlled environment

#

I think we should keep plugging away at the papercuts in the mean time. But also pursue dagger dev environments since they are valuable in and of themselves.

sweet hill
#

It just feels like a core tenet of the "Dagger way" is: "containerizing the problem is half the battle"

primal ridge
#

Yeah I totally agree

sweet hill
#

But we're not fully taking our own advice when it comes to dagger module dev pipelines

#

Anyway I agree on focusing on the papercuts for now. Just noodling on this in the meantime

primal ridge
#

We have done something very interesting by abstracting the language a given function is implemented in away from the caller (go module calls python module, etc.). So abstracting away all these other language-specific messes into some common interface does feel aligned with that idea somehow. There's definitely something here, at least in theory

sweet hill
#

push and pray, all day every day 😭