Specifying container of containers in configuration file

[pauldmccarthy]

Howdy,

I am trying to build a CLI application with an option that both expects multiple values, and can be given multiple times, e.g.:

myapp --option 1 2 3 --option 4 5 6

I want the values to be aggregated into a vector of vectors, so am using the following
code:

std::vector<std::vector<int>> option;
app.add_option(
  "--option",
  option,
  "Vector of vectors");

This works just fine when the --option values are specified at the command-line - I end up with a vector containing two vectors, which contain 1 2 3 and 4 5 6 respectively.

However there appears to be an issue when I try to specify the options in a configuration file, enabled via app.set_config("--config"). If I create a config.ini file with the following:

option = 1 2 3
option = 4 5 6

and run myapp --config config.ini, I end up with a vector which contains just one vector, containing 1 2 3 4 5 6.

Here is a minimal example which reproduces the issue:

#include <iostream>
#include <vector>

#include "CLI/CLI.hpp"

int main(int argc, char * argv[]) {

  CLI::App app{"MyApp"};

  std::vector<std::vector<int>> option;
  app.add_option(
    "--option",
    option,
    "Container of containers");

  app.set_config("--config");

  CLI11_PARSE(app, argc, argv);

  std::cout << "CLI11 version "
            << CLI11_VERSION_MAJOR << "."
            << CLI11_VERSION_MINOR << "."
            << CLI11_VERSION_PATCH << std::endl;

  std::cout << "Value for --option" << std::endl;
  for (auto &vec : option) {
    for (auto &val : vec) {
      std::cout << val << " ";
    }
    std::cout << std::endl;
  }
}

When specifying the values at the command-line:

./myapp --option 1 2 3 --option 4 5 6

I get the expected result:

CLI11 version 2.4.2
Value for --option
1 2 3
4 5 6

However, when I use a config file:

echo "option = 1 2 3"  > config.ini
echo "option = 4 5 6" >> config.ini
./myapp --config config.ini

I get:

CLI11 version 2.4.2
Value for --option
1 2 3 4 5 6

Thanks!

[phlptp]

Are you subvectors all the same length? If so you can specify that directly and it should split them via typesize.

You can also try ->inject_separator() on the option. I don't have time to build a test case for that right now, but that was designed to handle some similar situations.

[pauldmccarthy]

Hi @phlptp, thanks for replying! In my use-case the vectors will be of the same length, but that length is unknown at compilation time, so I am unable to specify the expected number of elements. Unfortunately adding ->inject_separator(true) / ->inject_separator(false) does not cause any change in behaviour.

[phlptp]

I am still playing with inject separator to try to figure out if that should be working on or not. however if you do this it should create a separator. This is how it is printed if config_to_str is used. though it does usually print it in one line

echo "option = 1 2 3 \"\" "  > config.ini
echo "option = 4 5 6" >> config.ini
./myapp --config config.ini

Multiple duplicate options are treated as 1 vector. What I am a little unclear about is whether what you had should be treated as two vectors or just one sequence. if it is single elements that should be a vector, but I don't know that we played through what the appropriate thing to do for multiple options in config with multiple elements and what would be most consistent.

[phlptp]

For reference, ->inject_separator() is implied for vector of vector operations, so setting that to true explicitly didn't really do anything.

In #1069 it does now manipulate the behavior of consecutive vector arguments with the same option in config file. It is on by default for vector<vector<>> but off otherwise but can be explicitly enabled or disabled.

[pauldmccarthy]

Hi @phlptp, thanks - thanks this seems to have improved things, as my example now produces the expected behaviour. However it seems to only handle vector options that are adjacent to each other. If I expand the example by adding a boolean flag, e.g.:

#include <iostream>
#include <vector>

#include "CLI/CLI.hpp"

int main(int argc, char * argv[]) {

  CLI::App app{"MyApp"};

  std::vector<std::vector<int>> option;
  app.add_option(
    "--option",
    option,
    "Container of containers");

  bool flag = false;
  app.add_flag(
    "--flag",
    flag,
    "Boolean flag");

  app.set_config("--config");

  CLI11_PARSE(app, argc, argv);

  std::cout << "CLI11 version "
            << CLI11_VERSION_MAJOR << "."
            << CLI11_VERSION_MINOR << "."
            << CLI11_VERSION_PATCH << std::endl;

  std::cout << "Value for --flag: " << flag << std::endl;

  std::cout << "Value for --option" << std::endl;
  for (auto &vec : option) {
    for (auto &val : vec) {
      std::cout << val << " ";
    }
    std::cout << std::endl;
  }
}

When interleaving --option with --flag, I again get the expected behaviour (what I would consider to be correct) when passing the options on the command-line:

CLI11 version 2.4.2
Value for --flag: 1
Value for --option
1 2 3
4 5 6

But when specifying the same options in a config file, e.g.:

option = 1 2 3
flag   = true
option = 4 5 6

the second value for --option is dropped:

CLI11 version 2.4.2
Value for --flag: 1
Value for --option
1 2 3

Perhaps I'm just misunderstanding how the 'container of containers' functionality is supposed to work? Ultimately what I'm after is the ability to aggregate a vector-of-vectors / list of lists:

• with consistent behaviour regardless of whether the options are specified at the command line or in a configuration file, and
• without requiring my users to adhere to a particular format or ordering, regardless of whether they use the command-line or a configuration file

Some additional context: I'm maintaining an existing application that uses an old vendored version of CLI11, which was hand-patched to produce the behaviour I'm after, and I'd really like to be able to use a modern vanilla copy of CLI11. For what it's worth, the patch we have been using is pasted below, although it is against an older version (2.2.0), and I'm not sure whether it would be the correct way to fix the behaviour.

Apologies for all the trouble!

---

Patch applied against include/CLI/App.hpp, in CLi11 version 2.2.0:

diff --git a/include/CLI/App.hpp b/include/CLI/App.hpp
index 0a70bac6..d79c9b37 100644
--- a/include/CLI/App.hpp
+++ b/include/CLI/App.hpp
@@ -2444,8 +2444,7 @@ class App {
             throw ConfigError::NotConfigurable(item.fullname());
         }
 
-        if(op->empty()) {
-
+        //if(op->empty()) {
             if(op->get_expected_min() == 0) {
                 // Flag parsing
                 auto res = config_formatter_->to_flag(item);
@@ -2454,10 +2453,18 @@ class App {
                 op->add_result(res);
 
             } else {
+                int min_num = (std::min)(op->get_type_size_min(), op->get_items_expected_min());
+                int max_num = op->get_items_expected_max();
                 op->add_result(item.inputs);
                 op->run_callback();
+                auto results = op->results();
+                for (const auto& result : results) std::cout << result << std::endl;
+                // if we only partially completed a type then add an empty string for later processing
+                if(min_num > 0 && op->get_type_size_max() != min_num && item.inputs.size() % op->get_type_size_max() != 0) {
+                    op->add_result(std::string{});
+                }
             }
-        }
+        //}
 
         return true;
     }

[phlptp]

What we need is for the command line to take precedence over anything in the config file. Changing this behavior would cause all sorts of issues, so we can't really change that. And this is effectively what your patch does. So what is happening with the multiple separated lines in the config file is it is loading the first, then on the next one it sees that the option already has information and thinks it is from the command line and ignores it.

Let me poke at it and see if there is a simple way of allowing this without breaking anything else.

[pauldmccarthy]

@phlptp thanks for looking into this; I had hoped that it would be a simple fix, so apologies for putting this on your plate. We can continue to use our patched copy (we typically exclusively use configuration files, so hadn't encountered any conflicts between command-line-provided and config-file-provided options).

[phlptp]

@pauldmccarthy I added a tweak that will merge config options even if separated in a single file.

app.get_config_formatter_base()->combineArguments();

would need to added to a config parser. This cannot be on by default as it would break some applications and use cases. And this won't work across multiple config files, but neither sound like your use case so I think it will work for

option = 1 2 3
flag   = true
option = 4 5 6

[pauldmccarthy]

Hi @phlptp, indeed, my toy example config file is now parsed successfully - thanks very much!

Unfortunately I have found another edge case - sorry! If I adjust the configuration file so that each values has length 1, or if each value has a different length, the config seems to be parsed incorrectly, e.g.:

expected: [[1], [2]], got [[1, 2]]:

echo "option = 1"  > config.ini
echo "option = 2" >> config.ini
./myapp --config config.ini

CLI11 version 2.4.2
Value for --flag: 0
Value for --option
1 2

expected [[1], [2, 3]], got [[1, 2, 3]]:

echo "option = 1"  > config.ini
echo "option = 2 3" >> config.ini
./myapp --config config.ini

CLI11 version 2.4.2
Value for --flag: 0
Value for --option
1 2 3

expected: [[1], [2, 3], [4, 5, 6]], got [[1], [2, 3], [4, 5, 6]]]:

echo "option = 1"  > config.ini
echo "option = 2 3" >> config.ini
echo "option = 4 5 6" >> config.ini
./myapp --config config.ini

CLI11 version 2.4.2
Value for --flag: 0
Value for --option
1 2 3
4 5 6

I should note that only the first of these use-cases (two vectors of length 1) is actually relevant to my use-case - in my particular application, the vectors should always be the same length, but I don't know what that length is at compilation time (it is determined by another option).

Apologies for continuing to drag this out, and thanks for your patience!

[phlptp]

I will take another look in a few days, currently on travel. I think the issue is with vectors of length 1, not the variable elements. The default in that case will always be to merge them together, but I will play around with changing that with the modifier mentioned above.

[phlptp]

@pauldmccarthy I added a tweak that will merge config options even if separated in a single file including single element
the modifier was renamed to better reflect the purpose.

app.get_config_formatter_base()->allowDuplicateFields();

[pauldmccarthy]

@phlptp I'm away from work at the moment, but will have a play with this when I'm back next week - thanks!

[pauldmccarthy]

Hi @phlptp, the allowDuplicateFields() option seems to have done the trick - all of the use-cases that I've had trouble with are now working! Thanks very much for your persistence, and sorry to be such a pain 👍

edit FWIW I tested my demo program with these options (both via the CLI, and via a config file), and verified that they are parsed correctly:

./myapp --option 1 2 3 --option 4 5 6
./myapp --flag --option 1 2 3 --option 4 5 6
./myapp --option 1 2 3 --flag --option 4 5 6
./myapp --option 1 2 3 --option 4 5 6 --flag
./myapp --option 1 2 --option 4 5 6
./myapp --flag --option 1 2 --option 4 5 6
./myapp --option 1 2 --flag --option 4 5 6
./myapp --option 1 2 --option 4 5 6 --flag
./myapp --option 1 --option 2
./myapp --flag --option 1 --option 2
./myapp --option 1 --flag --option 2
./myapp --option 1 --option 2 --flag
./myapp --option 1 --option 2 3 --option 4 5 6
./myapp --flag --option 1 --option 2 3 --option 4 5 6
./myapp --option 1 --flag --option 2 3 --option 4 5 6
./myapp --option 1 --option 2 3 --flag --option 4 5 6
./myapp --option 1 --option 2 3 --option 4 5 6 --flag
./myapp --option 1 --option 2 3
./myapp --flag --option 1 --option 2 3
./myapp --option 1 --flag --option 2 3
./myapp --option 1 --option 2 3 --flag