Allow creating GooseConfiguration from code

[samoylovfp]

Hi! Thanks for this awesome tool!

We use it to compare different implementations of our service against each other. Unfortunately there is currently no way to run GooseAttacks with different configs from the same process because there is a private field on GooseConfiguration which prevents its creation.

And when several -H flags are provided on the command line, gumdrop silently drops all but the last one.

We resort to spawning sub-processes with different command lines which causes some inconveniences.

[jeremyandrews]

You can configure defaults in code -- what are you trying to do that's different than this allows? https://book.goose.rs/config/defaults.html

[samoylovfp]

I also try to have my own CLI in the main process. Setting the defaults does not help with that since the initalization still tries to parse the arguments that are passed to our own "attack controller" and fails

[jeremyandrews]

What are you using to parse the CLI? In theory you should be able to make this work by dynamically setting the "defaults".

[jeremyandrews]

As Goose already "owns" the command line, I'd typically handle this with environment variables. For example, maybe something like:

#[tokio::main]
async fn main() -> Result<(), GooseError> {
    let custom_host = match std::env::var("HOST") {
        Ok(host) => host,
        Err(_) => "".to_string(),
    };

    GooseAttack::initialize()?
        .register_scenario(scenario!("LoadtestTransactions")
            .register_transaction(transaction!(loadtest_index))
        )
        .set_default(GooseDefault::Host, custom_host.as_str())?
        .execute()
        .await?;

    Ok(())
}

In this way, you can set a custom default, for example:

HOST="http://local.dev/" cargo run --release

And you can still override it from the command line, for example:

HOST="http://local.dev/" cargo run --release -- --host http://apache.fosciana/

[samoylovfp]

This is what I ended up doing, thanks for the hint!