I'd like to try moving clap in ./core behind feature flag - would a PR have a chance of being accepted?

[akavel]

I want to ask if this sounds reasonable to you (the authors of Nickel) before I start major work on this.

Background: I'm building an experimental app for configuration management (WIP). I'm using Nickel in it in an "embedded" way, for scripting - I only link with the nickel-lang-core crate. This crate is super heavy compared to the rest of my app, especially with regards to build time. I already isolated it to a separate crate in my app, to maximally reduce the frequency of recompiles needed. Still, from time to time, I hit this recompile for various reasons, and it's super painful to me. My first observation is, that nickel-lang-core seems to be using some dependencies that appear completely useless to my use-case - such as clap. This also sounds like something that doesn't necessarily comprise the "core" of Nickel language IIUC, thus it feels to me like possibly a "lowest-hanging fruit" when trying to slim-down the library. It could also possibly be a good "warmup" exercise for me, as a new contributor. As a hopefully smallest and least intrusive step, I would like to try moving the clap dependency (and any related code in ./core) behind a feature gate, for now enabled by default.

Does this sound reasonable? Would you consider such a PR (moving clap dependency behind a default-enabled feature flag in ./core/) for review and for possible merging if I were to try submitting it?

[jneem]

Yes, I think so. It looks like we're mainly using it for clap::ColorChoice, which is simple enough that we could just roll our own.