On the utility of Module::Build::CleanInstall
Not too long ago, I asked for input on a new module: Module::Build::CleanInstall.
TL;DR its out there, go use it!
As I explained there, I have heard several times that people would like the ability to remove installed files from a previous version of a module before installing the new one. A typical reason is that your old version contained some file that must not exist in the new one. Perhaps its an automatically detected plugin, or maybe some html file which is served from a static-files folder. Since the new version doesn’t contain these files they aren’t removed (or more properly, not overwritten) during installation of the new version.
Interestingly Leon Timmermans informed me of a part of the toolchain (both Module::Build and ExtUtils::MakeMaker) of which I had previously been unaware: namely that passing a build option uninst (with slightly different semantics in each) will trigger a certain uninstallation action in ExtUtils::Install::install(). Thinking that I had missed this easier mechanism for this task, I almost retracted my just release module. But then I decided to look further; the reason was the name.
The action is actually named uninstall shadows and that made me wonder. It turns out that when in effect, this flag causes ExtUtils::Install::install(), on each file during installation, to look for a matching file in several places around your @INC, and if they exist remove them. As such this flag doesn’t remove files that don’t exist in your new module, but rather it is intended to prevent confusion on the existence of the same file in multiple locations.
Therefore Module::Build::CleanInstall is both novel and useful. I hope it helps some module authors, and hopefully you have learned a little something about the toolchain (as I did)!
As a further note, I want to mention that this module is actually an offshoot of my (ever progressing) Alien::Base project. Remember that to fix a bug on Mac, I am now allowing an externally built module to install itself directly into a location relative to a File::ShareDir location. This meant that I was avoiding ExtUtils::Install::install() for those files, and it is that function that updates the packlist. For Alien::Base I wanted to be extra sure that I could allow full uninstallation of all related files using standard tools, therefore it must make an extra effort to be sure that the packlist is updated after these files are installed.
Given the extra knowledge I gained from that effort, Module::Build::CleanInstall was an easy implementation to help another different and real problem. So a measure of thanks go out to The Perl Foundation for funding me to help extend the toolchain, even if this was an unexpected benefit!
As I delve into the deeper Perl magic I like to share what I can.
Wow, that is quite craptacular, I really though —uninst would do something sensible. I’m wondering if we can still change it to do the sensible thing.
Would we want to change ExtUtils::Install::install() or M::B/EU::MM? It really is surprising that ExtUtils::Install::install() with the uninstall flag doesn’t call ExtUtils::Install::uninstall() isn’t it!
What it does do does have utility of its own. It’s really different sets of expectations at work. The situation seems to call for doc patches above all.