Add possibility to remove modules

[gerdint]

I.e. (kit/remove-module ) would do the inverse of kit/install-module

Would be useful in the case of failed experiments with a certain module.

[yogthos]

That might be a bit tricky because modules write to files in the project, and if the file is edited later then it could be difficult to tell where the code from the module is and whether it's safe to remove it.

[gerdint]

Yeah I can understand that this may be non-trivial to implement. One way would be to try to undo the module changes but bail out if there are any issues. I guess on underlying problem is the choice if the term "module", in that in reality the functionality is not really that modular at all (in the sense "self-contained"). And then there is the distinction to Kit "libraries" (which are actually modular in that sense), and the "profiles"...

[yogthos]

Yeah, ideally there would be a way to make modules truly modular, but that's a tricky problem in itself. The current modules are probably better described as templates. One thing that may be a reasonable compromise would be to remove the files added when a module is installed and then let the user know what code to remove from the existing project files. The modules already list the changes they make during the installation, so it would be easy enough to list that out. In most cases, the changes to existing files involve adding dependencies, requiring namespaces so they get loaded, and injecting components into system.edn. So, it shouldn't be too onerous on the user to roll these back manually.

[gerdint]

Yeah I've done the removal process by hand and in truth it's totally doable. So I understand if there are more highly prioritized things to work on. Coming up with a better term (be it template or not) may be the thing to start with...

[jwhitlark]

This is something I've missed, and have been thinking a bit about:

• Any sort of removal should check the git status is clean, for safety.
• For full files that are created, we could store the sha in the log, after it's been generated.
• • On removal, checksum is verified, and either removed or not, with a log message that it needs to manually removed, as it's been modified.
• For file modifications, we could save a patch, if the file hasn't been changed, it's easy to reverse, and if it has, we can print out the reverse patch and tell them that's what needs to be removed.
• • These changes are carried out with rewrite-clj/zippers, no? I'll have to review the implementation to be sure, but I seem to remember that changes are stored separately until ->root is called? That seems like it has potential.

Writing this out, maybe a starting place would be to generate a "Removal report". People can follow it manually, and if it works well enough, then we could automate it?

[yogthos]

The removal report would probably be a good place to start, and we already produce a report for what's been installed. So, and easy quality of life improvement could be to persist the report from the installation and then add a command to print it out.

[shevchuk]

I think there are better ways to do the removal such as Git branching, you could spin-up the new experimental branch and if the experiment failed, you just roll back.

[gerdint]

@shevchuk Well in this case I think I didn't have "experiments" in mind, more like several months down the road you switch to another db, markup generator etc.. Either way, unless modules become more like libraries removing may be difficult and fragile operation.