Feature | cast tasks arguments and values loaded through .env files to the correct type

[angelofenoglio]

What

Currently all parameters that a user provides to run a specific task are treated as strings. When these values are passed to the task during its invocation, they are still strings.
e.g.: in leverage task1[3,cleaup=True], task1 will be invoked with arguments "3" and cleanup: "True"
The burden of interpreting these string values correctly is up to the developer that writes such tasks.

The same happens with values loaded from .env files when using conf.load() in a task.

The proposal is to try and cast these input values into their correct data type.
To avoid challenging border cases maybe only a couple of types could be initially supported, such as booleans, integers and floats, and let everything that cannot be converted into these types be a string.

Why

It will ease the tasks developer job since it is a very repeatitive and error prone chore.

[angelofenoglio]

Another possibility would be to provide utilities to simplify this task, such as as_bool(), as_int() and as_float()

[exequielrafaela]

@angelofenoglio looking forward to your feedback :)

• OPT-1 | Enhancement | Issue #21 | OPT-1 | Implement typed argument casting #306
• OPT-2 | Enhancement | Issue #21 | OPT-2 | Implement typed argument casting #307

JIC Coded via OpenAI Codex: https://chatgpt.com/s/cd_6841c45c38fc8191882b5efb7c4bb3b1

CC: @diego-ojeda-binbash @Franr

[angelofenoglio]

Both PRs look very good!

I think I'm partial towards #307, I like the separation in different little functions, making it more testable.

Having said that, I would take both coderabbit's sugesstions. First, implementing the parsing logic instead of using the yaml library to parse booleans, it's overkill and a liability since the function called parses so much more than just booleans, creating a security situation. Second, reordering the casting to ensure values are properly converted.