#dang polish & escape hatches

1 messages · Page 1 of 1 (latest)

uneven hamlet
#

🧵 @candid silo

candid silo
uneven hamlet
#

Also - I mentioned my escape hatch for parallel. Basically I run my test execs lazily, and have them return a directory layer - then merge those before finaly sync

--> https://github.com/dagger/go/blob/main/go.dang#L180-L184

  """
  Run tests in every discovered Go module.
  """
  pub testAll(ws: Workspace!): Void @check {
    let layers = modules(ws).reduce(directory) { layers, mod =>
      layers.withDirectory(mod.path, mod.testLayer)
    }
    layers.sync
    null
  }
candid silo
uneven hamlet
candid silo
#

yeah point 1 should become unnecessary, you'll automatically get spans for each package and test

#

and if the tests are using testctx and have any custom spans of their own (like our integ tests) they'll be nested properly

uneven hamlet
#

Ah, so package will be a parent span? Not just attribute to be rendered by a new "test mode" renderer?

candid silo
#

i'll have to take a look, i think it's actually an attribute but the UI groups them by that as the toplevel hierarchy either way

uneven hamlet
candid silo
#

not yet, but they'll match

uneven hamlet
#

Ah 🙂 Just making sure dagger check out of the box looks as awesome & useful as possible

#

OK then - I'll focus on wrapping the helper

#

Much better than my previous (actually still current in main) hacky handrolled attributes anyway

candid silo
uneven hamlet
#

Should we bootstrap otel-go from source? Or download a binary?

candid silo
#

building from source is probably fine tbh, it's already in an environment that will be building Go code, much less work for us

uneven hamlet
#

Doesn't need to be generic parallel operations, can just be parallel withExec on a container, that would solve 90% of the actual problems

candid silo
candid silo
#

ah, like being able to sync multiple containers in parallel?

uneven hamlet
#

dang polish & escape hatches

uneven hamlet
candid silo
#

interfaces could be relevant here - my PR adds a interface Syncer { sync: ID! }, we could have a core API that takes those and syncs them in parallel

uneven hamlet
#

Yeah that's the generic verison. I'm just saying we can also implement something specific to Container and withExec that does not require interfaces, and would get 90%-ish of the job done

(as a parallel track)

#

But maybe interfaces are actually close enough to being truly usable for all, that it doesn't matter (I got used to interfaces being not actually usable in practice)

candid silo
#

i think it's close enough, my PR was practically done pending bikeshedding the API impact, just didn't make sense to push for merging it considering vacation timing + theseus being obviously higher prio

#

there's so much that finally gets cleaned up by it, i think it's worth just committing so it feels like a proper first-class feature

uneven hamlet
#

Does the "practically done" factor in SDK-wide work?

candid silo
#

yup, even the more fringe ones

uneven hamlet
#

nice

#

Is it actually the same kind of interface as before? Just working better? Or a completely new kind

#

I remember the horribly clunky need for 3 different modules - one to define, one to consume, one to implement...

#

And also the weird DX in Go

#

(not actually using go interfaces)

candid silo
#

Also eliminates all the dynamic schemas stuff, like the asFoo: Foo! interfaces conversions and Env.withFooInput; we don't need asFoo since they're just real interfaces now, and for APIs that can take "any object" now they can just take ID! instead of generating a million APIs for each type. Should be a big help for codegen reuse since now the core API can be truly static

#

the trade-off is that FooID! becomes ID! @expectedType(name: "Foo") - so the raw schema dump is more verbose, but it's at least more explicit than the string munging every SDK had to do before (HasSuffix("ID"), TrimSuffix("ID")), and it's necessary for GraphQL-level interface validation (separate ID types meant you could never satisfy a AnimalID arg with a CatID)

uneven hamlet
#

Seems amazing

uneven hamlet
#

@candid silo update on custom spans: I made github.com/dagger/helm which lints a 2-layer hierarchy of helm charts / values files. Would be nice to see the hierarchy in the spans

#

In this case the module code is the only reasonable place I could do it - doesn't seem worth to wrap helm in a custom helm-lint-otel tool

candid silo
#

so, dang spans?

#

or something in core?

uneven hamlet
#

I mean, that's the first tool I would reach for yeah (core or dang)

#

I guess if I'm wearing the module dev hat, I don't really care which.

Wearing the dagger maintainer hat, I'm sure I'll have opinions once I see specific designs

candid silo
#

is there a key point in the code you could point to? might illustrate which one's more natural

uneven hamlet
#

To try in practice:

cd ./dagger # can't -W yet
dagger -m github.com/dagger/helm check