Handling cli_flag and value appending

[rajavishah]

A nuance - cli_tag and cli_order aren't necessarily mutually exclusive, though in my experience, often if something has to be positioned at the beginning, it may not have a cli flag. But any of the following patterns are possible

someexecutable --unordered_flag_1 unordered_value_1 --unordered_flag_2 unordered_value_2 someexecutable unordered_value_1 unordered_value_2 someexecutable ordered_value_1 unordered_value_2 someexecutable --ordered_flag_1 ordered_value_1 unordered_value_2 someexecutable ordered_value_1 --unordered_flag_2 unordered_value_2

Originally posted by @bethac07 in https://github.com/bilayer-containers/bilayers/issues/36#issuecomment-2297501273

[rajavishah]

After discussing with @gnodar01 , we’ve agreed on the following approach to handle various cli_tag/cli_flag and value in the current code base.

The backend logic requires updates to handle cases based on parameter types.

A. Changes and behavior according to type of Parameters

1. type == Boolean There could be 3 cases/patterns how cli_tag and value could be appended with someexecutable

   |------------------|
   | cli_tag | value  |
   |------------------|
   |  Yes    |   Yes  |
   |  Yes    |   No   |
   |  No     |   Yes  |
   |------------------|

2. type != Boolean There could be 2 cases/patterns how cli_tag and value could be appended with someexecutable

   |------------------|
   | cli_tag | value  |
   |------------------|
   |  Yes    |   Yes  |
   |  No     |   Yes  |
   |------------------|

   Since, we can't foresee any cases where the cli_tag would only be appended without it's value

• Hence, the backend logic needs to be resilient to handle such Cases. Currently, it isn't able to handle the case where we only append the value without cli_tag

B. Changes in high-level keywords in config.yaml file

1. parameters (formerly inputs) : Helps appending either cli_tag or value or both to someexecutable
2. display_only (New Section): Doesn't append anything to someexecutable
3. results (formerly outputs): It's the right-side section of gradio (like the output section)

C. Display_Only Section and Why?

• Parameters that do not require appending cli_tag or value will be categorized under the display_only section. This includes information intended solely for user display in the interface, such as default output paths, which users cannot use through the cli_command. For example, if an algorithm's output directory path is hardcoded with it's natural behavior to save output-files and unchangeable, this path will be shown in the display_only section to help users understand where their files are saved. Hence, they could look into docker-desktop ---> Files ---> /path/for/output/files

[rajavishah]

On top of it, we will have cli_order for appending flags and values to the cli_command. We plan to implement this using a jagged/ragged array, as the insertion and search operations will have constant time complexity. The idea is to store all unordered cli_tags in the 0th column, while ordered cli_tags and values will be appended in columns 1 to n

[bethac07]

Since, we can't foresee any cases where the cli_tag would only be appended without it's value Hence, the backend logic needs to be resilient to handle such Cases. Currently, it isn't able to handle the case where we only append the value without cli_tag

I think this can just be handled by the fact that cli_tag will be "", yes?

The harder case to handle in my opinion is the booleans; we might need to think more through the nuances there.

[bethac07]

(But great summary!)

[rajavishah]

Since, we can't foresee any cases where the cli_tag would only be appended without it's value Hence, the backend logic needs to be resilient to handle such Cases. Currently, it isn't able to handle the case where we only append the value without cli_tag

I think this can just be handled by the fact that cli_tag will be "", yes?

The harder case to handle in my opinion is the booleans; we might need to think more through the nuances there.

Yeah, but in the scenario where Algorithm's Documentation is having cli_tag for some of the parameter, and the algorithm's executable structure expects us to only append value. Would there be a case like that? Or it would be the case where cli_tag won't be present at all if the executable's structure is to just take value?

[bethac07]

Or it would be the case where cli_tag won't be present at all if the executable's structure is to just take value

Yes, if there is no preceding flag, the person filling out the config shouldn't add one

[rajavishah]

The harder case to handle in my opinion is the booleans; we might need to think more through the nuances there.

For type == Boolean, I feel there are 6 cases

1. If cli_tag is present and value is True|Yes --> someexecutable cli_tag True|Yes
2. If cli_tag is present and value is False|No --> someexecutable cli_tag False|No
3. If cli_tag is present and value is True|Yes --> someexecutable cli_tag
4. If cli_tag is present and value is False|No --> someexecutable
5. If cli_tag is "" and value is True|Yes --> someexecutable True|Yes
6. If cli_tag is "" and value is False|No --> someexecutable False|No

I've confusion with case 6 - Would the logic should behave like append False or if it's False don't append anything with someexecutable?

[gnodar01]

Although I could imagine them as possible, the last two cases are incredibly rare (for booleans), to the point that I've happily never encountered it in the wild.

We might consider taking 5. and 6. out as possibilities for the boolean type.

What is still rare, but common enough that I have encountered once or twice, is a positional value that is single choice / select (i.e. a dropdown of a finite, predefined set of values).

So you might have algo_name [flags] [choice A | choice B | choice C ], where you can optionally have only one of Choice A or Choice B or Choice C, or none of them.

Or you might have algo_name [flags] (choice A | choice B | choice C), where you must have one and only one of Choice A or Choice B or Choice C.

We could use the above type for the very rare, if not nonexistent cases of 5. and 6.

In the case of 5. and your first interpretation of 6., we would have:

algo_name [flags] [True | False]

In the case of 5. and your second interpretation of 6., we would have:

algo_name [flags] (True | False)

Or Yes | No, Doit | Dontdoit, please | nothanks, etc.

So the type would be Select (or Dropdown or Choice or whatever we name it), and the value would be an array which just so happens to have exactly two values, True and False, and there would be a required field which if false or not set, would allow none as an option, and if true or set would not allow none as an option.

[rajavishah]

Although I could imagine them as possible, the last two cases are incredibly rare (for booleans), to the point that I've happily never encountered it in the wild.

We might consider taking 5. and 6. out as possibilities for the boolean type.

What is still rare, but common enough that I have encountered once or twice, is a positional value that is single choice / select (i.e. a dropdown of a finite, predefined set of values).

So you might have algo_name [flags] [choice A | choice B | choice C ], where you can optionally have only one of Choice A or Choice B or Choice C, or none of them.

Or you might have algo_name [flags] (choice A | choice B | choice C), where you must have one and only one of Choice A or Choice B or Choice C.

We could use the above type for the very rare, if not nonexistent cases of 5. and 6.

In the case of 5. and your first interpretation of 6., we would have:

algo_name [flags] [True | False]

In the case of 5. and your second interpretation of 6., we would have:

algo_name [flags] (True | False)

Or Yes | No, Doit | Dontdoit, please | nothanks, etc.

So the type would be Select (or Dropdown or Choice or whatever we name it), and the value would be an array which just so happens to have exactly two values, True and False, and there would be a required field which if false or not set, would allow none as an option, and if true or set would not allow none as an option.

Got it, Thankyou!

[rajavishah]

@gnodar01 and I, were discussing about what else we should support at making the cli_command.

1. cli_order with negative values

   • Previously, we vaguely brainstormed around this but more concretely we thought maybe let's just do something like if user puts cli_order as negative value. The cli_command construction behavior should be someexecutable positive_cli_ordered_flags unordered_flags(i.e. cli_order=0) negative_cli_ordered_flags

2. Some of the many patterns of generating cli_command would be

   • someexecuatble --flag=value -flag2 -value2 ...
     • So, should we also give out support for stuff in appending with = rather than {white-space-between-flag-and-value}?

• someexecutable --flag1 value1_for_flag1 value2_for_falg1 value3_for_flag3

  • Should we give support for appending n number of values for the same flag? It's like when we receive the list of values for the same flag?

• someexecutable --flag1 value1 --flag1 value2 --flag1 value3

How common are those patterns and for which-n-all we want to provide support for?

[rajavishah]

Implemented