Idea: argument validation system

[wolfgang42]

I was thinking last night about the argument validation we've been discussing in #122. I had the idea of an allow_empty_string config setting, but then I thought—why should the empty string be special? There are a lot of different validations that might be important for an argument, such as whether the file exists or if the value is an integer.

To that end, here's a straw-man proposal for a validations system:

• Flags and arguments have a new config key, validate, which takes an array of validations to check the value for. (Optional: If there is only one validation, it can be passed as a bare string.)
• Validations are defined by a function named validate_${validation_name} which takes one argument, the value to be validated, and echos a string if the value is not valid.
• Bashly has some built-in validations, but additional ones can be defined in lib/ by individual programs.

Here are some example validations which people might write:

validate_not_empty() {
  [[ -z "$1" ]] && echo "must not be empty"
}
validate_file_exists() {
  [[ -e "$1" ]] && echo "must be an existing file"
}
validate_commit_exists() {
  git rev-parse --quiet --verify "$1^{commit}" || echo "must be a valid git commit"
}
validate_is_integer() {
  [[ "$1" =~ ^[0-9]+$ ]] || echo "must be an integer"
}

And an example config:

commands:
- name: upload
  args:
  - name: source
    required: true
    validate: file_exists
  flags:
  - long: --scratch-file
    validate: [file_readable, file_writable]

WDYT?

[DannyBen]

Seems like a great idea.

One correction though: initialize.sh is probably not the best place for this. Users who want to add custom validation can just add validation functions - each in its own file, or all in a single file - under the lib folder. Bahly encourages the practice of one file, one concern.

[wolfgang42]

Yes, you're right, I'm not sure why I said initialize instead of lib. I've edited the description to fix that.

[DannyBen]

Another point for consideration:

We can treat these validations as an extra feature, which works like this:

1. You run bashly add validations
2. This simply creates several lib/validate_X.sh files with all the validations we want (or a single lib/validations.sh).
3. We just add the hook before allowing arg/flag to pass, that runs all the validation functions provided in the YAML config (and of course failing gracefully if the function is undefined).

The reasoning for this:

All validation functions - be it custom user validation, or build in validation - get the same treatment and live in the same place. This also allows tweaking and removing validations you don't need.

Without this kind of implementation, we will have to add custom strings in the strings config, which will then mean that "native" validations and custom validations have a different way to configure them.

[cjbrigato]

EDIT: posted too slow, previous post propose great usage details that would immediately fit in our workflows
Looking forward this one, considering that it would produce even more insightful usage / feedack
Aside from a step up toward making the script self documenting, it also provides safetyness without the cost, and shell scripts are definitely lacking on this matter.

One of the first validation that I'd look for would be named custom validation, so it's good if a script can be generated in the /lib or dedicated directory that represent such validation and is customisable the same way as command generated scripts.

[DannyBen]

so it's good if a script can be generated in the /lib or dedicated directory that represent such validation and is customisable

Right, I also feel like that. Everything under lib (and sub directories) is loaded into bashly. Right now running bashly add lib adds a sample function there. I think it fits nicely with the validations concept, and if needed they can all be placed under lib/validations if it feels more natural and organized to everybody.

I feel this is a relatively easy to implement concept.

@wolfgang42 - should I take first stab at this?

[wolfgang42]

Making the builtin validations a library definitely seems like a good idea! Yeah, please do have a go at implementing it.