On 21 March 2017 at 09:09, Doug Bell <madcity...@gmail.com> wrote: > > How can the user interactively fix a configuration problem that would also > then be considered a failure in configuration? If the configure script > allows it, it must be normal operation, no? If it involves editing the > config script, that's a different run (and an edited dist, which is not good > report fodder).
I've done this a lot lately. "oh, no . in @INC bug? oh, *inject use line* try again cpanm!" cpanm --interactive lets that happen. And that of course generates possible strangeness in the logs, which cpanm-reporter then does something with. Seems fine in MI/EUMM's case, but I saw some spooky stuff I then tried to forget about when it was Module::Build NA *is* appropriate because my system "doesn't support the configuration as is", because the system requires "." in @INC But if the module itself isn't broken, and the tests aren't broken, reporting that as "install/tests failed" is wrong. But reporting no failure is also wrong, cos config is broken but I worked around it. -- Kent KENTNL - https://metacpan.org/author/KENTNL
