> On Mar 20, 2017, at 3:45 PM, Kent Fredric <kentfred...@gmail.com> wrote: > > 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. >
I tried testing this using `cpanm --interactive`: I created a Makefile.PL with only "die 'OS unsupported'". When I run `cpanm --interactive .`, it dies, and does not seem to allow me to edit anything or run anything to prevent it from dying. `cpanm --look` would let you see the thing before you install it, but you're altering the dist at that point. I'm mostly asking to see how common a scenario this is, because it sounds like something I've not seen before. > And that of course generates possible strangeness in the logs, which > cpanm-reporter then does something with. cpanm-reporter can't know you altered the dist, so I would really suggest not sending in reports for dists you've altered, as they could be more confusing than insightful: You sent in two reports from a Perl without "." in @INC, but one failed because of it, and one succeeded in spite of it. Does the second report indicate that "." got added to @INC somehow? > 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. In this scenario, which is different from your previous scenario, it would be reported as "configure failed" (so, NA). As I understand cpanm-reporter, you sent in 2 test reports: one configure failed (missing "." in @INC), one passed. I can't think of any way for the configure step to fail and yet the installing client will still try to continue. The rest of your previous scenario is still possible: You could run cpanm under the "--force" flag, fail the tests, and then still fail to install. And for that, it seems best for the failure step reported to be the "test" step.
