Hi. Is it still true we have to use

<http://sigs.k8s.io/yaml|sigs.k8s.io/yaml>

in flytectl: https://github.com/flyteorg/flytectl/blob/cea39d9bdf2476f9a5313d1bf19bf08b3923237a/cmd/create/execution_util.go#L13. I'm asking because it depends on go-yaml v2, which does not support yaml 1.2. More specifically, it has weird handling of

n

,

y

,

no

,

yes

, etc. when coming to key name, see https://github.com/go-yaml/yaml/issues/214. If an input argument is named as

n

, when creating an execution via a execution spec file, that argument must be quoted as

"n"

, otherwise flytectl would fail because when unmarshalling

n

is parsed as

false

as the argument name.

Seems we use gopkg.in/yaml and sigs.k8s.io/yaml https://github.com/flyteorg/flytectl/blob/master/go.mod#L37 https://github.com/flyteorg/flytectl/blob/master/go.mod#L42 We can remove the dependency which is causing the issue and make use of just one. Would be great if you can help with a contribution to fix this issue

Of course I can give it a try. Yeah I noticed two yaml libs are being used and that was the reason I was wondering when using that sigs fork/wrapper was required to handle struct.

Not that i know of any limitations due to which chose to have both and it might just be IDE suggestion and auto import causing both dependencies to exist and never caught in code review process. BTW i noticed for writing the execution config we use gopkg here Whereas for reading the execution config we use sigs.k8s here So they both seems to be compatible with each other so should be fine to keep one. Noticed also kubernetes code base they have references to both these . gopkg doesn’t seem to be maintained and doesn’t have any new major release whereas sigs.k8.yaml does. So might be useful for us to consider that too when choosing what to use

I created https://github.com/flyteorg/flyte/issues/3483. I tried to work on a fix, but did find that these two libs behave differently. More details in the issue and let's follow it up there.