On 22 March 2017 at 06:48, Doug Bell <[email protected]> wrote: > > My opinion would be, yes, that the reporter tool would need to send in two > reports in this particular situation, leaving the original issue of "what > status to assign to the report" as "the furthest step completed without > error".
As it stands, this produces a serious viability problem for me. If I do anything less than what I'm doing, one of a bunch of things I don't want will happen. 1. If I simply bail out and set PERL_USE_UNSAFE_INC=1 ... well, that bleeds too far, it starts the tests passing too prematurely, and of course, it spreads to the dependencies that load *after* configure. 2. If I use a strategy *other* than the interactive edit, then there's no way I can report the result of the tests, either pass or fail,... Because I need to run Makefile.PL to get the tests passing, but the combination of cpanm and cpanm-reporter will not file a report if I've locally checked out sources somewhere and modified them through means other than the interactive hack I've demonstrated earlier. Ideally, I want to report the tests /after/ I've circumvented the issue in configure, but without having to globally change things in ways that make the test pass. ie: I want to expose .-in-@INC issues independently in the different phases without conflating the two, but "I have to circumvent configure" means effectively "I can't report on tests", and this is very sub-optimal. -- Kent KENTNL - https://metacpan.org/author/KENTNL
