Hi team, another question about the difference between METAFLOW_RUNTIME_NAME vs. METAFLOW_RUNTIME_ENVIRONMENT? My use case involves a custom plugin and it needs to skip some logic if it’s running locally vs. on k8s. I observed that

METAFLOW_RUNTIME_ENVIRONMENT

is set to

kubernetes

correctly in my k8s pod when I start my flow with

--with kubernetes

but

METAFLOW_RUNTIME_NAME

doesn’t. Can I rely on the METAFLOW_RUNTIME_ENVIRONMENT to tell me which env I’m in?

Hi, these are internal implementation details that can change at any time. what's your usecase?

Thanks Savin for following up on this! thankyou So I have a custom

FlowDecorator

that calls

subprocess.run(

to run poetry, kubectl etc.. What I observed is that the

flow_init

logic is executed in both scenarios: 1. when I submit the job locally as in

poetry run python ./flow.py --environment=pypi run --with kubernetes

. (it would have access to kubectl, poetry etc. tools install locally) 2. when metaflow sets up the pod in k8s. (it won’t have access to kubectl, poetry etc) So in my custom decorator, I need to skip these logic if it’s running on remotely. Thus I need something like:

if RUNTIME_ENVIRONMENT == "local":
    do_some_local_validation() # access poetry, kubectl etc.

Would something like this work out of the box for you https://docs.metaflow.org/metaflow/configuring-flows/parsing-configs#using-common-formats-like-toml-and-yaml

Ah this feature is helpful! (And this can trigger a thread of thought on how we can architect the plugins to leverage this feature more. ) But it didn’t solve my issue directly though as the custom plugin does more than just parsing the toml. (E.g. (a) it also uses kubectl, (b) we prefer to utilize the poetry utils to parse its toml and (c) there’re some plugin logic to load first party dependencies as well that doesn’t translate to any existing annotation)