Runtime-configurable responses?

[GoldsteinE]

Hi! It would be fun if cargo-mommy supported runtime loading responses.json with custom responses.

[VixieTSQ]

Would require adding clap to the project, which may complicate things... Unless we want to add more environment variables (pls no). Clap would complicate things because we have to know where the cargo-mommy arguments end, and where the cargo commands begins. I suggested that we change cargo-mommy from being an extension to a simple standalone binary but Aria said no. But I think that would fix #7 and make this issue easier to fix.

[GoldsteinE]

JSON could be loaded from a standard location like $XDG_CONFIG_HOME/cargo-mommy/responses.json

[catuhana]

Would require adding clap to the project, which may complicate things... Unless we want to add more environment variables (pls no). Clap would complicate things because we have to know where the cargo-mommy arguments end, and where the cargo commands begins. I suggested that we change cargo-mommy from being an extension to a simple standalone binary but Aria said no. But I think that would fix #7 and make this issue easier to fix.

Instead of CLI thingy with flags, something like confique can be used.

[catuhana]

Would require adding clap to the project, which may complicate things... Unless we want to add more environment variables (pls no). Clap would complicate things because we have to know where the cargo-mommy arguments end, and where the cargo commands begins. I suggested that we change cargo-mommy from being an extension to a simple standalone binary but Aria said no. But I think that would fix #7 and make this issue easier to fix.

Instead of CLI thingy with flags, something like confique can be used.

I implemented it on my fork, but there are some things:

1. Default values are now in config.rs file, that's OK for pronouns and roles configuration, but Responses struct's macro is so long, and I think isn't good for maintainability. What can be done instead?
2. Options are still String instead of Vec<String> and needs to be split with function since there's no way to set Vector (or array) with environment variables. Probably needs to be done from confique's (the runtime configuration library used) side.

And recommendations/opinions?

[VixieTSQ]

Would require adding clap to the project, which may complicate things... Unless we want to add more environment variables (pls no). Clap would complicate things because we have to know where the cargo-mommy arguments end, and where the cargo commands begins. I suggested that we change cargo-mommy from being an extension to a simple standalone binary but Aria said no. But I think that would fix #7 and make this issue easier to fix.

Instead of CLI thingy with flags, something like confique can be used.

I implemented it on my fork, but there are some things:

1. Default values are now in `config.rs` file, that's OK for pronouns and roles configuration, but `Responses` struct's macro is so long, and I think isn't good for maintainability. What can be done instead?

2. Options are still `String` instead of `Vec<String>` and needs to be split with function since there's no way to set Vector (or array) with environment variables. Probably needs to be done from confique's (the runtime configuration library used) side.

And recommendations/opinions?

Responses really should be a path to a responses file. Just make it a pub responses: Option<Path> and bring back the include_str. Or pub responses: Option<Responses> if you really think it's that much better to have it right in the config file.

[catuhana]

Responses really should be a path to a responses file. Just make it a pub responses: Option and bring back the include_str. Or pub responses: Option if you really think it's that much better to have it right in the config file.

I created responses.toml file to include it in the compiled file for default values with include_str, but its still configurable by cargo-mommy.toml. Is this OK? If not I will split responses.toml and cargo-mommy.toml (still will bundle responses) and responses.toml will be separated.

[VixieTSQ]

Responses really should be a path to a responses file. Just make it a pub responses: Option and bring back the include_str. Or pub responses: Option if you really think it's that much better to have it right in the config file.

I created responses.toml file to include it in the compiled file for default values with include_str, but its still configurable by cargo-mommy.toml. Is this OK? If not I will split responses.toml and cargo-mommy.toml (still will bundle responses) and responses.toml will be separated.

That's sounds good to me!

[catuhana]

Responses really should be a path to a responses file. Just make it a pub responses: Option and bring back the include_str. Or pub responses: Option if you really think it's that much better to have it right in the config file.

I created responses.toml file to include it in the compiled file for default values with include_str, but its still configurable by cargo-mommy.toml. Is this OK? If not I will split responses.toml and cargo-mommy.toml (still will bundle responses) and responses.toml will be separated.

That's sounds good to me!

Done. If it looks good I will create a pull request.
https://github.com/tuhanayim/cargo-mommy/commit/32671e6ca24fa2c4687b4a64ef64404c4045141c

[VixieTSQ]

Responses really should be a path to a responses file. Just make it a pub responses: Option and bring back the include_str. Or pub responses: Option if you really think it's that much better to have it right in the config file.

I created responses.toml file to include it in the compiled file for default values with include_str, but its still configurable by cargo-mommy.toml. Is this OK? If not I will split responses.toml and cargo-mommy.toml (still will bundle responses) and responses.toml will be separated.

That's sounds good to me!

Done. If it looks good I will create a pull request. tuhanayim@32671e6

Go for it!