Flyte enables production-grade orchestration for machine learning workflows and data processing created to accelerate local workflows to production.

Flyte

I ran the followinf example:
<https://github.com/flyteorg/flyte-sdk-rs/tree/main/examples/hello-trace|github.com/flyteorg/flyte-sdk-rs/…/hello-trace>

cargo test -p hello-trace <-— works
cargo build <— works
./target/debug/hello-trace <— ERROR

```./target/debug/hello-trace
flyte worker configuration error: system error: missing required configuration: pass --name or set ACTION_NAME```
The same error happens when i run it as a flyte task in the container.

The dockerfile directly runs the binary:
`RUN  cd app && cargo build --release --bin hello-trace && install target/release/hello-trace /usr/local/bin/hello-trace`

`flyte-sdk/src/flyte/_internal/imagebuild/docker_builder.py` method `_build_image`. Also we need a way to pass `“--platform”, dynamically. Currently it’s taking it from `image.platform` which defaults to `linux/amd64`

<@U085FDMUZFD> i checked it out, firstly thank you for trying.

1. Running the binary directly is expected to stop with that error. It's the worker that runs inside the task container, and the backend fills in ACTION_NAME, RUN_NAME etc when it launches the pod. For local dev, cargo test runs the task in process, and ./hello-trace describe-interface prints its interface. I've improved the error message so it now explains all of this and lists everything that's missing.

2. If you hit the same error in a pod actually launched by the backend, that would be a real bug. The v2 backend injects those env vars into every task pod, so can you share the pod spec (env and args) or the pod logs? My guess is the pod failure you saw was actually the image arch: the builder defaults to linux/amd64, so on an arm64 node the container fails to start.

For that last part I've added platform control: rust_task(..., platform="linux/arm64"), or set RUST_IMAGE_PLATFORM. The python image builder also gets a FLYTE_DOCKER_BUILD_PLATFORM env var. Will push these shortly.

Thanks. I have added platform tag to rust plugin in rs repo, and tried that yesterday.

I think the problem is with `imagefromvenv` . So my venv is 3.12/3.13, but when you do `apt install python/python-dev` and set `PYO3_PYTHON` as python3, it installs 3.11 bcoz 3.12 i think is still not available. so i get `libpython3.12.so.1.0: cannot open shared object file` error from the pod.

I made some changes to UV_TEMPALTE_CODE_IMAGE as well, will try it out later today.

flyte-sdk -&gt; adding changes to make UV related environment configuable
- #1467
#1467

flyte-sdk-rs -&gt; adding changes to accomodate uv venv for all python version
- #11
#11

I have raised 2 pr’s for the issue