[Suggestion]: Feature-gate templating

[jonaro00]

Add a feature templating that activates liquid and chai dependencies and functionalities. (enabled by default)

This allows projects that depend on cargo-generate as a library to fine-tune what functionalities to use, and to strip away some dependencies. An example of this is cargo-shuttle init command, which uses the auto_path parsing and git cloning functionalities, but does not intend to use templating.

In general, it would be nice to see the various parts of cargo-generate be more modular to use as library functions.

Is this a reasonable feature request?

[Sven Kanoldt]

Is this a reasonable feature request?

I guess yes, the question is more, how is this intended to work?
I mean if others want to use cargo-generate as a library, then they can do it already.

So maybe you can spec out a use case with an example project where a more "lightweight" cargo-generate with fewer dependencies is intended to be used?

Because I have a hard time imagining how this all should work.
E.g. without liquid as a dependency: how would one use cargo-generate then? Just to copy over files that don't require any templating? Or with rhai pre-processing only?

Right now it's an use-all-or-nothing cargo-generate, but to draw some lines the use cases must be quite well-defined and understood. Maybe I'm myself are a bit too less creative to forsee those use cases, that's why let's write them up here to have a design spec that we then can discuss.

[jonaro00]

As stated, my main example and the reason for this idea is cargo-shuttle's init command. The functionality used there is

1. Parsing of the auto_path config variable to allow for different types of URLs and shorthands etc,
2. Cloning of the specified repo/folder, and
3. Optionally extracting a subfolder in the repo and using that to set up the new project.

Cargo-generate was probably chosen and used as a library due to (2) and (3) being fulfilled, with (1) being a nice bonus. The templates used in cargo-shuttle do not use any of the templating features (they are cloned plain and simple), and as far as I know, does not intend to use them.

Currently, the cargo_generate::generate function is used, which uses all features whether or not they are desired. It is also the only "usable" public function of the library. The feature isolation could be done by either separating and pub'ing the functions that generate uses, or just make the cargo feature flags modify the behavior of generate.

These are the things that can potentially be isolated as standalone features: (Not sure if all are possible, I have a shallow understanding of the codebase)

1. Reading local cargo-generate config files, such as favorites.
2. Reading config file in template
3. Rhai (limits behavior of template config file)
4. Liquid (same as above)

(1) and (2) are very lightweight and can probably be kept without adding weight to such use cases.
The more tangible improvements in dependency weight are if (3) and (4) are optional features (separate or together).

This is my motivation for allowing such a stripped-down version of cargo-generate. Arguably, use case with the three features at the top could implement those behaviors themselves, but the work is already nicely done here.

[Sven Kanoldt]

I had a look into that and toyed around with a PoC and it's a hell load of work and the code base needs a major restructure in order to have not a widespread of repeating feature gates all over.

And the only value-add is lesser dependencies on some use cases.
I'm sorry but it's not convincing enough.