krystian-wojtas
commented
4 years ago I tried some prove of concept. Actually it is implemented with structopt, not clap. Just to give some idea.
I found that structopt has method from_iter which I can use instead of from_args. Then I can provide some subgroup of all parameters and invoke it few times as many sensors are defined by provided user command line parameters.
To split all parameters in such subgroups I used Vector::split function with custom delimiter --sensor.
Code
Here is implementation with only 2 such sensor parameters
// Standard modules paths
use std::env;
use structopt::StructOpt;
#[derive(StructOpt, Debug)]
#[structopt()]
pub struct OptGeneric {
// Socket
/// Address of interface to bind
#[structopt(long, default_value = "0.0.0.0")]
socket_interface: String,
/// Number in decimal
#[structopt(long, default_value = "9898")]
socket_port: u16,
}
#[derive(StructOpt, Debug)]
#[structopt()]
pub struct OptSensor {
/// Number in decimal
#[structopt(long, default_value = "1")]
sensor_i2c_bus: usize,
/// Number in hexadecimal
#[structopt(long)]
sensor_i2c_address: Option<u8>,
}
#[derive(Debug)]
pub struct Config {
generic: OptGeneric,
sensors: Vec<OptSensor>,
}
impl Config {
pub fn parse(args: std::env::Args) -> Config {
// Split command line arguments into groups separated by '--sensor' delimiter
let arguments: Vec<String> = args.collect();
let mut sensor_parameters_groups = arguments.split(|argument| argument == "--sensor");
// First group of parameters is generic without any information for specific sensor
let generic_parameters = sensor_parameters_groups.next()
.unwrap();
// Parse generic parameters
let generic = OptGeneric::from_iter(generic_parameters);
// Create vector for sensors to be parsed
let mut sensors = Vec::new();
// Iterate over rest of groups each containing complete sensor information
for sensor_parameters in sensor_parameters_groups {
// OptSensor::from_iter is going to skip first item, so it have to be put anything to be skipped
// TODO maybe StructOpt::from_iter should not skip first item to not have to workaround it?
let array_with_empty_item = [String::from("")];
let iter_with_extra_first_item = array_with_empty_item.iter().chain(sensor_parameters);
// Parse each sensor information
let sensor = OptSensor::from_iter(iter_with_extra_first_item);
// Fill sensors vector
sensors.push(sensor);
}
// Return result
Config{generic, sensors}
}
}
fn main() -> Result<(), Box<dyn std::error::Error>> {
// Parse configuration
let config = Config::parse(env::args());
// Debug purpose only
println!("{:#?}", config);
// Return success
Ok(())
}
Run
Invocations are like that:
-
without any arguments
% cargo run -- Finished dev [unoptimized + debuginfo] target(s) in 0.04s Running `target/debug/prometheus_sensors_exporter` Config { generic: OptGeneric { socket_interface: "0.0.0.0", socket_port: 9898, }, sensors: [], } -
some sensors
% cargo run -- \ \ `# generic configuration` \ --socket-interface=1.1.1.1 \ --socket-port=10000 \ \ `# 3 physical sensors located on physycial different i2c bus or address` \ --sensor \ --sensor-i2c-bus=0 \ --sensor-i2c-address=1 \ --sensor \ --sensor-i2c-bus=0 \ --sensor-i2c-address=2 \ --sensor \ --sensor-i2c-bus=1 \ --sensor-i2c-address=1 \ > Finished dev [unoptimized + debuginfo] target(s) in 0.04s Running `target/debug/prometheus_sensors_exporter --socket-interface=1.1.1.1 --socket-port=10000 --sensor --sensor-i2c-bus=0 --sensor-i2c-address=1 --sensor --sensor-i2c-bus=0 --sensor-i2c-address=2 --sensor --sensor-i2c-bus=1 --sensor-i2c-address=1` Config { generic: OptGeneric { socket_interface: "1.1.1.1", socket_port: 10000, }, sensors: [ OptSensor { sensor_i2c_bus: 0, sensor_i2c_address: Some( 1, ), }, OptSensor { sensor_i2c_bus: 0, sensor_i2c_address: Some( 2, ), }, OptSensor { sensor_i2c_bus: 1, sensor_i2c_address: Some( 1, ), }, ], } -
help message
% cargo run -- --help Finished dev [unoptimized + debuginfo] target(s) in 0.04s Running `target/debug/prometheus_sensors_exporter --help` prometheus_sensors_exporter 0.1.2
USAGE: prometheus_sensors_exporter [OPTIONS]
FLAGS: -h, --help Prints help information -V, --version Prints version information
OPTIONS:
--socket-interface
### Questions
- Is it some valid approach?
- Could clap be used to implement something similar?
- How to include sensors parameters into help message?
- There is some workaround in `array_with_empty_item`. Library is going to skip first element, so I have to provide anything to be skipped. Does clap also requires such workaround?
pksunkara
CreepySkeleton
leshow
epage
elkowar
Isaac-Leonard
cavivie
What are you trying to do?
I have group of options which could be used multiple times. All such groups should be kept without overwriting previous one.
--sensorspecifies instance of new group. Then suboptions are only for current group.Ideally parsing would generate instance of Vector\<Sensor> defined something like
Could it be possible?
Or maybe would you recommend to model it in some another way which could be easier to implement?
What have you tried already?
I tired few examples, but I didn't find anything similar so far.