Interaction between env and many?

[teohhanhui]

Considering there's no support for splitting an argument by a delimiter value, like clap's value_delimiter: https://docs.rs/clap/4.1.6/clap/builder/struct.Arg.html#method.value_delimiter

There seems to be no way to set multiple values by an environment variable?

[pacak]

Not directly but you can always use parse to your advantage to replicate value_delimiter - getting a single argument and splitting it.

fn parse_ports(in: String) -> Result<Vec<u16>, String> {
    ....
}

#[derive(Debug, Clone, Bpaf)]
#[bpaf(options)]
struct Opts {
    #[bpaf(argument::<String>("PORTS"), env("PORTS"), parse(parse_ports))]
    ports: Vec<u16>
}

many is about being able to parse a single option argument multiple times. You can still use it along with env but since behavior for parsing is going to be different - parsing many times and splitting by comma - you'd use two different parsers, compose them with construct! and use with external.

fn parse_ports(in: String) -> Result<Vec<u16>, String> {
    ....
}

#[derive(Debug, Clone, Bpaf)]
#[bpaf(options)]
struct Opts {
    #[bpaf(external(get_ports))]
    ports: Vec<u16>
}

fn get_ports() -> impl Parser<Vec<u16>> {
    let by_env = long("ports").env("PORTS").argument("PORTS").parse(parse_ports);
    let by_many = long("port").argument("PORT").many();
    construct!([by_env, by_many])
}

[pacak]

Yup, many + env = bug, thank you for giving me a fresh look at my code ❤️

[teohhanhui]

I actually can't find a way to do the flat_map as discussed.

I've looked at the code here:

bpaf/src/structs.rs

Lines 513 to 519 in 6c22fd3

	while let Some(val) = parse_option(&self.inner, args, self.catch)? {
	if args.len() < len {
	len = args.len();
	res.push(val);
	} else {
	break;
	}

And it seems like the parse_fn or map_fn I supply would only ever receive individual argument items. There's no way to transform the entire Vec.

[pacak]

Complete examples for combinatoric and derive implementeations

use bpaf::*;
use std::str::FromStr;

// --ports 1,2,3 --ports 4,5   => [1,2,3,4,5]
fn args() -> impl Parser<Vec<u16>> {
    long("ports")
        .help("Comma separated list of ports")
        .argument::<String>("PORTS") 
         // at this point we are working with a parser that consumes a single
         // --ports and produces a single String
        .parse(|s| {
            s.split(",")
                .map(|c| u16::from_str(c))
                .collect::<Result<Vec<_>, _>>()
        })
        // at this point we are still consuming single --ports but produce a vector
        // of u16 that was inside of it, or the parser will fail and give user an error
        // message if input was invalid
        .many()
        // many repeatedly applies parser it has been applied to and collects results
        // into a vector, so parser here returns a vector of vectors and map on the
        // next line will flatten them.
        .map(|nested| nested.into_iter().flatten().collect())
}

fn main() {
    println!("{:?}", args().to_options().run());
}

Derive solution performs basically the same steps but instead of closures it takes functions

use bpaf::*;
use std::{num::ParseIntError, str::FromStr};

fn split_and_parse(s: String) -> Result<Vec<u16>, ParseIntError> {
    s.split(",")
        .map(|c| u16::from_str(c))
        .collect::<Result<Vec<_>, _>>()
}

fn flatten_vec(vv: Vec<Vec<u16>>) -> Vec<u16> {
    vv.into_iter().flatten().collect()
}

#[derive(Debug, Clone, Bpaf)]
#[allow(dead_code)]
struct Opts {
    #[bpaf(
        long,
        argument::<String>("PORTS"),
        parse(split_and_parse),
        many,
        map(flatten_vec)
    )]
    /// Comma separated list of ports
    ports: Vec<u16>,
}

fn main() {
    println!("{:?}", opts().to_options().run());
}

[teohhanhui]

Gotcha. It hadn't quite occurred to me that the attributes to the derive macro are chained like that. I feel like I'm one (small) step closer to understanding what "combinatric" / "applicative functor" means now 😂

[pacak]

Gotcha. It hadn't quite occurred to me that the attributes to the derive macro are chained like that.

I see, need to work on my documentation then. This feedback is very valuable, if you have anything else to add about what was confusing at the beginning or still is - feel free to ask.