Best way of handling dependencies when using clap_complete at compile time

[tmccombs]

I'm currently using clap_complete with generate_to in the build.rs to generate completions at compile time. However, I'd also like to start using custom value_parsers with clap 3.2. The problem is that if I add the value_parsers for a custom type that pulls in a dependency on other modules, which I can't do when running as build.rs.

What's the recommended way of dealing with this?

Some possibilies I've thought of:

1. Have build.rs create a cfg flag that I can use for conditional compilation to pull in the dependencies. But conditionally adding a .value_parser is kind of messy.
2. Create a separate file that is creates dummy parsers for any custom parsers used, and include that in build.rs
3. split out the custom parsers into another file that is imported (or part of the same cli.rs file). This might not be feasible depending on what the parser does, and might pull in additional dependencies as dev dependencies as well as being regular dependencies.

Any recommendations or best practices on how to deal with this?

[epage]

Heh, bringing derive features into the builder API also brings derive complications. Its been a while since I've provided completions in my programs, so I don't have first hand experience with this.

A variant of cfg would be to use a macro to either skip calls or put in dummy values.

Note that some value parser affect completions

• Imply value_hint = ValueHint::AnyPath for PathBuf/Option<PathBuf> #3840
• If it provides possible values

We are also exploring an alternative approach to completions that cannot be built in a build.rs (#3166). If/when that is ready, I'm assuming we'll drop the level of support for the existing completions (which is already "not great" which is why we want to go this alternative approach)