quick question In specific regards to

[signal canopy]

It's pretty integral to the design; the Git API for example just translates to another type of value in the Buildkit graph, just like containers

[errant basin]

that's what I figured, just wanted to confirm. Thanks 🙂

[rigid kite]

@errant basin why would you want to do this?

Was the idea to be able to use dagger.GitRef or dagger.GitRepository functions outside of a Dagger Pipeline running in a Dagger Engine so you have one consistent way of doing things from one implementation?

In what contexts would you need to avoid running in a Dagger Engine? Why? 🙂

[errant basin]

yeah basically we have some automation we are setting up that reuses some code, and we thought that doing git operations outside of the dagger context would avoid us having to use a different git lib like pygit2 or gitpython. But it's not a huge deal to just use two libraries, and create the data structure inside the pipeline from data that we derived when we ran pygit2 outside the pipeline.

The context here is that we are wrapping a lot of our dagger code into a CLI that runs ci. But also this CLI does other things that aren't running CI. For those outside-of-ci use cases, you sometimes don't want the overhead of spinning up a dagger container for commands that aren't needing dagger (these are one-off commands that take almost no time and are basically never repeated in a fashion that makes sense to cache, things like simple API operations), but you do want all of the git information at that point usually.