Compose imported config with additional items about bashly

[DannyBen]

Aloha. I think this was mentioned and discussed somewhere, but I don't remember where or what was the conclusion.
Let me play with it a little, see what can be done.

Thanks for the detailed ticket in the meantime.

[dabrady]

Whoa, I've never even heard of GitHub "Discussions" 🤯 Or I would have gone there first. I see the tab at the top of the repo now, awesome, will definitely start there next time unless I'm actually raising an issue. Anywho, thanks again!

[DannyBen]

Found where it was discussed: #273

[DannyBen]

So, here are some pointers. This is a long one, so strap in.

YAML must be a valid YAML

As you discuvered, the below is invalid:

flags:
  import: src/common_flags.yml
  - long: --debug

There are two validations that take place:

1. The YAML itself must be valid before anything else (and the above is not valid YAML).
2. After the YAML is valid, it is loaded to Bashly, which can validate its schema.

Pre-processing with Kojo

The above syntax requires processing the YAML file as a text file (before using YAML.load_file). This is outside the scope of Bashly.

As it happens, I have tool for that, named Kojo. With it you can pre-process the bashly.yml file as follows:

# bashly_src.yml
name: cli

flags:
  @import common_flags
  - long: --debug

# common_flags.yml
- long: --json
- long: --quiet

$ kojo file bashly_src.yml
name: cli

flags:
  - long: --json
  - long: --quiet
  - long: --debug

If you choose this solution, your "build" step will be something like this:

$ kojo file src/bashly_src.yml --save src/bashly.yml && bashly generate

Importing individual flags

You can still use bashly's native import in a merged context. You just need to merge the individual elements (flags):

# bashly.yml
name: cli

flags:
  - import: src/flag_quiet.yml
  - import: src/flag_json.yml
  - long: --debug

# src/flag_json.yml
long: --json

# src/flag_quiet.yml
long: --quiet

Global flags

If you have flags that appear in all subcommands, you can put them on the root command:

# bashly.yml
name: cli

flags:
  - long: --debug

commands:
  - name: download
    flags:
      - long: --json

$ ./cli --debug download --json
args:
- ${args[--debug]} = 1
- ${args[--json]} = 1

Anchors

As you mentioned, using YAML anchors is another way of solving this issue (example). Personally, I find it the most straight forward.

---

With all these options, I do not feel there is a need to complicate it further.

Don't forget that the bashly.yml is just the skeleton configuration - if it becomes so large that you need to consider alternatives that are not presented here, I suspect the problem lies elsewhere.

Also - I consider the import feature, more of a leaf in the implementation, rather than a branch, which means that expanding it further must have an epic reasoning, and a very simple implementation.

I hope one of these options points you in the right direction, and am still open to discuss further.

[dabrady]

Thanks @DannyBen for that in-depth and clear response, it is very helpful to me. 🤙🏻 Consider this question answered! (I couldn't figure out how to add the question label myself btw, or I would have chosen that over enhancement.)

As I am in the very beginning of my CLI project, anchors will probably be entirely sufficient, and I do like the explicitness of that technique. I'm definitely bookmarking your kojo project though, that looks like an awesome utility. 👏🏻

[DannyBen]

Sure thing Daniel, glad I could help.

Questions are usually more suited for the Discussions section, but I might add a Question issue template.
If you are having any more issues or questions that are not easily answered in the docs, do not hesitate to open an issue or a discussion. Bashly should be easy to pick up, if it isn't - its a bug.