nested includes

[yosefy]

hi, any chance we can make it possible
missing this feature so much

meaning in included config, there will be another include which depends on values from parent include

thanks

[ashitr]

This would help, allowing to ask further inputs based on previous inputs provided.

[yosefy]

exactly! actually this is the main goal, i couldn't explain it good, thanks you know what... may be we can just add some type of "depends_on (list)" field in script properties, which will show this parameter only when list of other param is chosen wow this would be so cool this way we will avoid not needing multiple files to include and can put them all in the same file? @bugy what do you think? thanks

…

On Thu, Nov 23, 2023 at 11:59 AM Ashit Rai ***@***.***> wrote: This would help, allowing to ask further inputs based on previous inputs provided. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[bugy]

Hi, @yosefy could you describe your use case a little bit more detailed? As for me, "depends on" and "include" have slightly different usages:

• "include" should be used for "reusable" configurations, i.e. when multiple scripts use the same configuration
• "depends on" should be used for dynamic visibility of parameters

I guess the main confusion here, is that script server allows "dynamic include", which is probably has nothing to do with reusability. And actually, in many cases, it causes duplicity, because people have to introduce several "included" files for different parameter values.
I think, my preferred solution here would be to add something like enabled option for each parameter, which will call some script and depending on the script results, might include the parameter.
It should be more flexible than depends on, since it will allow to enable a parameter for certain values and even depend on some other conditions (e.g. time of a day 😅)

What do you think?

[yosefy]

use case: first (main) conf: - choose list of ansible playbooks (only playbooks drop down list shown) - if playbook is "install_prometheus_exporter.yaml" show new list of vars that playbook "install_prometheus_exporter.yaml" needs and playbook B needs another list of vars second (include 1) conf: lets say we choose playbook A which is "install_prometheus_exporter.yaml" for example now we see more vars in ui; hosts_list (hosts to install on) exporter_type (node_exporter, mysql_exporter, java_exporter) now that we choose exporter type (in included config), depending on type there are different set of. vars for java_exporter we need java_version for mysql_exporter we need may ber mysql_version, exporter_version, and mysql_server and for node exporter we need nothing ================= hope it will help to choose the right way to implement thanks

…

On Mon, Nov 27, 2023 at 11:22 AM Iaroslav Shepilov ***@***.***> wrote: Hi, @yosefy <https://github.com/yosefy> could you describe your use case a little bit more detailed? As for me, "depends on" and "include" have slightly different usages: - "include" should be used for "reusable" configurations, i.e. when multiple scripts use the same configuration - "depends on" should be used for dynamic visibility of parameters I guess the main confusion here, is that script server allows "dynamic include", which is probably has nothing to do with reusability. And actually, in many cases, it causes duplicity, because people have to introduce several "included" files for different parameter values. I think, my preferred solution here would be to add something like enabled option for each parameter, which will call some script and depending on the script results, might include the parameter. It should be more flexible than depends on, since it will allow to enable a parameter for certain values and even depend on some other conditions (e.g. time of a day 😅) What do you think? — Reply to this email directly, view it on GitHub <#722 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADCXF3KV4ZO7CK6H3Y7TSA3YGRLT5AVCNFSM6AAAAAA7VRKTLGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRXGQ2DMMJSGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>