#SDKs stability

1 messages · Page 1 of 1 (latest)

topaz elm
#

No, between Go, Python and TypeScript, they can be considered as stable, but sometimes in the rush of bringing in big changes, there may be slight differences.

For example, Go Modules have support for defining interfaces, but not the others. This week we launched a big change for supporting OpenTelemetry in v0.11.0 and with Go SDK support included, but not the others.

Python had support for OTEL but was removed last minute because of what happened with Beartype, and due to timezone differences in our team, they couldn't wait for me to quick fix the failing CI check in the OTEL PR.

It's rare that these differences happen. They're more on the fringe or newer side. You can understand that most of dagger's codebase is in Go, and we have more Go developers so it's easier to stay a little ahead. With OTEL, it just means you can’t create your own custom “spans” in Python functions with this release. But it's so new and no one's using it yet.

Python does have a few features/conveniences not in the others. Same thing, these things lie in the fringe or experimental and undocumented. But for anything important all 3 are considered as stable and supporting the same features. The other SDKs rely more on community contributions so that’s where you’ll see more differences.

#

Let me explain what happened with Beartype, but first a bit of context. Some languages have differences due to the maturity of their tooling. Go’s tooling is very unifying and simple. Python on the other hand, is a very old language, with many users across a variety of environments and needs. This has resulted in a very fragmented ecosystem on tooling, and it has made it very difficult to create standards and unification.

At Dagger, we’ve tried to adhere to existing standards as much as possible, to avoid lock-in into any one tool. However, since there’s no standard yet for a lock file mechanism, until v0.11.0, Python didn’t lock the module’s dependencies. Any time you created a new module or ran an existing one, it would always install latest versions based on open constraints in the SDK. If you had an existing module, however, you could pin in your pyproject.toml’s dependencies.

Go and TypeScript don’t have this issue, as they both support locking natively.

Circling back to Beartype, the project released a new version that was a breaking change for Dagger. We can’t fix it quickly on our side because changing the constraint in the SDK takes a whole release of Dagger. But it’s also not a good idea to constrain using an upper bound by default because that’s more limiting for users most of the time.

With v0.11.0, due to adding support for uv in https://github.com/dagger/dagger/pull/6884, the Python SDK automatically generates a requirements.lock file and uses that to install the dependencies when running dagger call. So if a dependency creates a breaking change again, you won’t be affected for existing modules, and it’s easy to fix for new modules as well.

#

@hardy olive, as you can see it was an accident, and not foreboding on the stability of the SDK. If you do have errors, please report them. They can come from the core API, which affects all SDKs, and they can happen for any SDK, but we work hard on having them fixed as soon as possible.

I have no idea what you mean by Error: unknown command "from" for "dagger call ...". Have you reported it? It could be many things, probably not related to the SDK.

empty steppe
topaz elm
#

It looks like that, but doesn't fit in with unknown command ... for "dagger call". If it were a typo, it'd be a Python syntax error.

hardy olive
#

@topaz elm thanks for the explanations. So it seems a good idea to move to Go. As for Error: unknown command "from" for "dagger call ...", the issue happens when running the dagger call <function-name> but it does not happen if running dagger run main.py nor running python3 main.py. the only references to the keyword from i have is on imports. Tested on linux and mac, it fails on linux but not on mac... fails also on CI using an alpine image

topaz elm
hardy olive
#

Yes i know that with dagger call, we cannot use gad.host, to give you an example of what i have

hardy olive
#

FYI i found out why we had this issue Error: unknown command "from" for "dagger call ..., we where passing a strin argument with space containing the from keyword, and depending on the os the interpretation was different. Example export MESSAGE="message from faco" dagger call <function-name> --message=$MESSAGE

#

on mac it worked but on linux it failed