zsv config file

[iamazeem]

Hi @liquidaty,

I was looking into the extension config file which currently is in .ini format i.e. zsv.ini.
I was wondering about te usage of the INI format for the config file here.
yajl is already being used so why not use the JSON format instead? 🤔
It'll be one less dependency i.e. removal of inih library.

Here's a sample JSON config:

{
    "log_level": "debug",
    "...": "...",
    "extensions": [
        {
            "name": "ext1",
            "path": "/path/to/ext1",
            "enabled": false
        },
        {
            "name": "ext2",
            "path": "/path/to/ext2",
            "enabled": true,
            "config": {
                "extension_specific_config_string": "string",
                "extension_specific_config_array": [1, 2, 3],
                "...": "..."
            }
        }
    ]
}

In addition to ZSV_CONFIG_DIR, a new CLI flag --config-file may also be introduced e.g.:

zsv --config-file ~/my-zsv-config.json

The --config-file will take precedence over the default one.

---

Another thing that I was thinking about is to enhance the extension model to support shell scripts and external executables.
For the end users, it'll be easier and faster to use scripts and/or executables written in their own language of choice.
Though, I'm not sure whether this is feasible or not. Just wanted to share to the idea here.

Here's a sample JSON config for this:

{
    "extensions": [
        {
            "id": "ext1",
            "name": "dynamic-extension",
            "type": "dynamic-library",
            "path": "/path/to/dynamic-extension.so",
            "enabled": true,
            "config": {}
        },
        {
            "id": "ext2",
            "name": "shell-script-extension",
            "type": "script",
            "path": "/path/to/shell-script-extension.sh",
            "args": ["--arg1", "value1", "--arg2", "value2"],
            "enabled": true,
            "config": {}
        },
        {
            "id": "ext3",
            "name": "external-executable-extension",
            "type": "executable",
            "path": "/path/to/external-executable-extension",
            "args": ["--arg1", "value1", "--arg2", "value2"],
            "enabled": true,
            "config": {}
        },
        {
            "id": "ext4",
            "name": "pipeline-extension",
            "type": "pipeline",
            "args": ["ext1", "ext3", "ext2", "ext1"],
            "enabled": true,
            "config": {
                "skip_on_error": true
            }
        }
    ]
}

The ext4 is reusing other configured extensions i.e. it is a pipeline (sequential execution).

LMK what you think about it. Thanks!

[liquidaty]

JSON vs .ini may be a good idea, I'm sure we considered and don't recall why ended up w .ini. In any case, not sure it's worth retooling now esp as others may be using the .ini approach already (though I don't know for sure).

As for supporting shell scripts and external executables in extensions, my main question would be: what would be the main benefit of doing so i.e. how would the envisioned solution ux compare with what it would currently be without the envisioned solution?

[iamazeem]

JSON vs .ini may be a good idea, I'm sure we considered and don't recall why ended up w .ini. In any case, not sure it's worth retooling now esp as others may be using the .ini approach already (though I don't know for sure).

Given that zsv is still in alpha, this may be reconsidered. 🤔
YAML may also be considered as a potential format instead of JSON.

As for supporting shell scripts and external executables in extensions, my main question would be: what would be the main benefit of doing so i.e. how would the envisioned solution ux compare with what it would currently be without the envisioned solution?

This would make zsv more accessible to non-devs and/or devs who don't have experience with the current extension model.
It would provide the plug and play functionality to quickly switch between external tools if need be.
Currently, piping zsv output to other exes is the way to go.
This may be discussed under its own separate issue.
Based on its feature requests, this may be explored further if it adds any value for the community.