Do we have metaflow client api in any language other than python? For example, Go, Java, Rust? I have not seen anywhere yet, but curious if anyone has tried such a thing. Use case is to be able to get the flow/run/task information from a service. Using the metaflow service rest api directly feels too low level and risky in terms of version upgrades.

right. We don’t have a public API or other SDKs available yet but they are on the roadmap

Correct, those are the primary use cases. To list them out, 1. List all runs of a Flow 2. Describe details of a Run 3. Inspect artifacts or logs from a Run 4. Check status of a Run 5. Trigger

MetaflowEvent

with a payload (this translates to ArgoEvent, at least for us)

thanks. At least some of these you can do with the CLI today (

logs

,

dump

,

trigger

etc), which you can call from any language runtime

I opened an issue here to track the roadmap item. Please comment to upvote the issue

At least some of these you can do with the CLI today (

logs

,

dump

,

trigger

etc), which you can call from any language runtime

Hi @victorious-lawyer-58417 is there a way to trigger a workflow without having access to the source of the workflow? This is kind of what we need to be able to trigger a Flow through another service. Triggering through events is one way I can think of, but it will be nice to be able to trigger the exact workflow. The events can be listened to by multiple workflows, so it is not a super precise mechanism.

you can do

python helloflow.py argo-workflows trigger

on the CLI. When you combine that with

@project

and

--branch

etc, it'll trigger a specific variant of the flow

Right, so in the case of events, people can subscribe to events someone else is using, unintentionally. And when an event is triggered from another service, it is hard to know exactly which workflows will trigger. We need some static analysis and validation to avoid this.

if you need secure boundaries making sure that flows and events have a hard separation with no chance of overlap (intentional or unintentional), then you can create separate deployments. We support this in Outerbounds out of the box or you can create separate OSS deployments manually. In general though I haven't seen issues related to people accidentally listening to wrong events. It takes deliberate effort to type

metaflow.DataTriggerFlow.end

or something like that, but I understand the concern