Bug #94611 for Dist-Zilla-Plugin-Git: win32 support appears dysfunctional

Thu Apr 10 13:22:27 2014 ether [...] cpan.org - Ticket created

Subject:

win32 support appears dysfunctional

this makes me a sad panda: http://matrix.cpantesters.org/?dist=Dist-Zilla-Plugin-Git+2.020 Other git plugins seem to work on windows - what's up with the dreadful test results here?

Thu Apr 10 13:30:44 2014 ether [...] cpan.org - Correspondence added

Mithaldu just tried installing this and he says he gets exactly this: http://www.cpantesters.org/cpan/report/21a51a34-6c0c-1014-ae06-cb9d3ff8c583 this looks fixable.

Thu Apr 10 14:09:13 2014 ether [...] cpan.org - Correspondence added

More about win32 issues... looks related to kentnl's Path::Tiny patch... 10:54 < Mithaldu> https://metacpan.org/source/CJM/Dist-Zilla-Plugin-Git-2.020/t/Util.pm#L160 needs to be slurp_raw with decode_utf8 i guess 10:57 < ether> Mithaldu: why? slurp_utf8 should dtrt there 10:58 < Mithaldu> haarg: need a bit of help then, at what point in the code would you think that fits in? 10:58 < Mithaldu> ether: i don't think it does, but let me try 10:59 < ether> Mithaldu: maybe an issue for Path::Tiny then? 11:00 < Mithaldu> ether: wrong end 11:00 < Mithaldu> the file that's written contains \r\n 11:03 < ribasushi> need a one-line invalid yaml 11:03 < ribasushi> was it tab? 11:04 < Mithaldu> ether: yup, the diff to 2.019 indicates that the previous version slurped files with :crlf intact, instead of binmoding things 11:04 < Mithaldu> so now he HAS binmode there and its exposing something else

Thu Apr 10 23:39:00 2014 cjm [...] cpan.org - Correspondence added

The issue appears to be that when Kent rewrote my slurp_text_file to use Path::Tiny's slurp_utf8, he didn't consider that (unlike my code) it doesn't do :crlf translation on Windows. That broke the tests on Windows. I didn't notice because I haven't been able to get dzil installed on my new Windows machine because it doesn't pass its tests. I haven't had time to debug it. (I do most of my development on Linux these days.) Just FYI, the error is Syntax error at line 2: 'n ' at C:\Users\cjm\.cpanm\work\1397185963.4496\Dist-Zilla-5.015\blib\lib/Dist/Zilla/Util/AuthorDeps.pm line 35. # Looks like your test exited with 255 before it could output anything. t/commands/authordeps.t ...... Dubious, test returned 255 (wstat 65280, 0xff00) Failed 1/1 subtests I believe the Git plugins are working ok; it's just the test that has a problem. There doesn't seem to be any way to get slurp_utf8 to do :crlf, so the simplest thing is probably to go back to the old code.

Thu Apr 10 23:39:00 2014 The RT System itself - Status changed from 'new' to 'open'

Fri Apr 11 00:02:35 2014 ether [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #94611] win32 support appears dysfunctional
Date:	Thu, 10 Apr 2014 20:59:45 -0700
To:	"Christopher J. Madsen via RT" <bug-Dist-Zilla-Plugin-Git [...] rt.cpan.org>
From:	Karen Etheridge <ether [...] cpan.org>

Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=94611 > > > The issue appears to be that when Kent rewrote my slurp_text_file to use Path::Tiny's slurp_utf8, he didn't consider that (unlike my code) it doesn't do :crlf translation on Windows. That broke the tests on Windows. > > I didn't notice because I haven't been able to get dzil installed on my new Windows machine because it doesn't pass its tests. I haven't had time to debug it. (I do most of my development on Linux these days.) Just FYI, the error is > > Syntax error at line 2: 'n > ' at C:\Users\cjm\.cpanm\work\1397185963.4496\Dist-Zilla-5.015\blib\lib/Dist/Zilla/Util/AuthorDeps.pm line 35. > # Looks like your test exited with 255 before it could output anything. > t/commands/authordeps.t ...... > Dubious, test returned 255 (wstat 65280, 0xff00) > Failed 1/1 subtests

That looks like corpus/dist/AutoPrereqs/dist.ini is being executed as a .pl file... very odd! Show quoted text

> I believe the Git plugins are working ok; it's just the test that has a problem. There doesn't seem to be any way to get slurp_utf8 to do :crlf, so the simplest thing is probably to go back to the old code.

I'm sure there's a way; I'll poke the file layer experts.

Tue Apr 15 19:11:14 2014 KENTNL [...] cpan.org - Correspondence added

https://metacpan.org/source/CJM/Dist-Zilla-Plugin-Git-2.021/lib/Dist/Zilla/Plugin/Git/NextVersion.pm#L110

It is my suspicion that this code:

if (defined $last_ver) {

($head) = $git->rev_parse('HEAD') unless $head;

print { $cachefile->openw } "$head $last_ver\n";

return $last_ver;

}

Causes the file to have an "\r" in it in the first place.

My suspicion is all you need to do to fix this test failure is change ->openw to either openw_raw or openw_utf8 , and the "\r" will not be injected absolving you from needing to have :crlf on the decoding side.

Sat Jun 14 12:10:06 2014 cjm [...] cpan.org - Fixed in 2.021 added

Sat Jun 14 12:10:07 2014 cjm [...] cpan.org - Correspondence added

Resolved by https://github.com/madsen/dist-zilla-plugin-git/commit/b922685843aa4afb4a6990f0c9ddad48ec6bcdcd and released in 2.021.

Sat Jun 14 12:10:13 2014 cjm [...] cpan.org - Status changed from 'open' to 'resolved'