#What does `dagger develop` actually _do

1 messages · Page 1 of 1 (latest)

rugged talon
#

I've been rereading the docs this afternoon and haven't found anything which addresses this -- if I'm right I'd definitely recommend adding a note about not needing to commit the sdk folder

untold pasture
#

dagger develop instructs the SDK to generate all files required for a working dev environment. Then it writes them to your local directory. This allows your own dev tools - IDE, etc - to work without errors.

#

You're right that the generated files don't need to be committed to git. There are different best practices for handling generated files in git, and we have flip-flopped between them.

  • One approach is to not commit them. This uses .gitignore as you described.
  • Another approach is to commit the files, but designate them as generated using .gitattributes.

There are pros and cons. At the moment I think we don't use gitignore by default, but have decided that we should.

You can safely add all the generated files to .gitignore yourself. They are not used at execution (dagger re-generates everything at runtime)

rugged talon
#

Interesting -- I didn't know there was a something in .gitattributes for generated files. So is it all types for LSP support? Because if you have a module installed, its type signatures aren't necessarily even defined in the same language you're developing in, so dagger has to generate type signatures for your imported dagger modules in the language you've created the SDK for?

untold pasture
#

And indeed this is for LSP, linters etc

rugged talon
#

I see! I was also curious if it was going to be possible to use the (now-legacy?) API client paradigm (dagger run ...) with modules, but I suppose necessarily this would not support type definitions for imported dagger modules.

#

Sounds like it was a very difficult engineering decision to make to decide to add the function execution environments for each SDK into the dagger model. @untold pasture As a user, it feels like there's a tradeoff in risk and complexity between using the basic GQL client from a host language, and using the modules and functions platform knowing that the execution environment will have to go through upgrade cycles in the future. I'd be curious to hear your take on this!

untold pasture
#

Actually we had this planned from the start, ever since we launched multi-language SDKs over a year ago 🙂

The difficult decision was to cut the Functions/Modules feature last year, to give ourselves more time to design it, and make it good

#

We had to compromise and make do with an incomplete DX for a year, which was painful but necessary.

#

We expect the stability of the functions runtime environment to be equivalent to the stability of the rest of the Dagger API. That is to say: probably not perfect, but we will make a conscious effort to either avoid breaking changes altogether, or failing that, to make them as painless as possible.

In other words: if you have a dependency on Dagger, you might as well take full advantage of it, and use functions.

rugged talon
#

Very cool! I'm excited to start "daggerizing all the things" and learning how to push its limits in the coming year. Just relistened to the earliest Dagger appearance on Changelog's Ship It! and it was a great reminder of some of the fundamental ideas, even if that was back in the Cuelang era. Great work from you and all the daggernauts!