[Feature Request / Idea]: cache user input and reuse when same backpack is applied

[strowk]

Suggestion / Feature Request

At the moment backpack is nice and simply used generator that can be used without issues when new project is being created from some sort of template.
I was trying to use it in a little bit different fashion by reapplying it again and again as the "base" template changes. For example imagine a bunch of microservices that are combined from same (one or more) backpacks - things like CI/CD and IaC are often duplicated and it would be great if they could've been reapplied from the same template whenever that template changes.

Backpack already supports such case by overwrite option. However, what I find inconvenient is that if template contains some parameters (like f.e name of microservce, amount of replicas, resources, other configs), we have to enter them again every time. This also does not allow to simply enforce the content of "generated" (or "cloned" files) in something like a git hook, because it would be too inconvenient to use and possibly could result in mistakes when input is wrongly entered.

So I have a suggestion to store this metadata inside of "cloned" project (dunno the right term). I had this idea of calling it a "camp" (cause this is what you get when backpack is .. unpacked :) ). So backpack (if camp is used) would've create a folder ".backpack-camp" and keep there a file, say "interaction-answers.yaml", writing it when user enters answers and reading and using it when backpack is re-applied ( with "-w" most likely ).

I have created a PR ( #14 ) with the example implementation for discussion. The PR have a certain issues though at the moment. It works, but poorly tested and contains at least one bug (does not work that well for "confirm" interaction when user selects No). Plus, as changes are needed in another crate as well (which I made in the fork here - strowk/interactive-actions@d11b5c3 ), temporary they are included via "git" dependency, which also should be fixed by pushing changes to "interactive-actions" upstream, but firstly I need to understand if this idea would be able to go through at all.

There are couple issues that are already clear in the implementation as it is:

When interaction response is handled here - https://github.com/rusty-ferris-club/backpack/pull/14/files#diff-ac2bedd3bcd2e9bf422921fb0677dcc861a67971da18649c3fca4f792cd6cc38R137 it is not possible by the type of response to understand whether it is a boolean or text, because interactive actions crate returns text in all cases ( this - https://github.com/jondot/interactive-actions/blob/master/interactive-actions/src/data.rs#L174 ) except when "confirm" input was No - then nothing is returned. This means that entering No and not having that confirm interaction in older version of backpack - are indistinguishable from that point. It is possible, of course, to assume that since we run the interaction and there is nothing in response that would indicate that answer was Yes ( Response::Text("true") ), then in means we have to cache "false". This, however, seems like a nasty workaround. The alternative would be to change Response enum to support returning typed results for "confirm" (and probably "select" as well for uniformity), but this would've been a breaking change, that would require rolling the major version (1 -> 2).

Additionally, as I believe it is possible (and rather sensible) to need to apply more than one backpack to one "microservice", it might be possible that different backpacks would have questions with the same identifiers and for this, the implementation need to keep answers separated by some sort of id of backpack (shortlink probably?).
This I haven't addressed yet as well, but it is already clearly needed.

So for now I just wanted to ask what do you think of this approach and these issues I have described.