Dealing with IO::Capture bugs

Xiong has asked for the wisdom of the Perl Monks concerning the following question:

Soon-to-be-released Devel::Comments has a build_requires (test) dependency on IO::Capture and friends. Other stuff in the pipeline has the same or a stronger dependency.

IO::Capture::Tie_STDx 0.05, which does the heavy lifting for various IO::Capture modules, has two bugs. It incorrectly handles say(); and it fails to implement a TELL() method.

I emailed the author, Mark REYNOLDS, over two months ago; no reply. Granted, I haven't yet made a concerted effort to contact. Given, I should. I needed these bugs fixed immediately so, that's what I did.

I have written two modules, IO::Capture::Sayfix and IO::Capture::Tellfix. Each, on load, makes a quick test to see if the corresponding bug has been fixed in the currently loaded ::Tie_STDx; if so, it does nothing; else it fixes the bug on the spot. ::Sayfix redefines PRINT(); ::Tellfix defines TELL(). This approach is intended to play well with the existing version of ::Tie_STDx as well as any future version in which either, both, or neither of these bugs are fixed.

Before writing ::Sayfix, I patched a copy of the existing ::Tie_STDx. I was told by other Monks, in no uncertain terms, that even to install such a thing locally was to ask for trouble.

Seeking some direction on how to proceed. One or more of:

File formal bugs on RT.
Ping REYNOLDS heavily via email and any other available route.
Prepare a formal patch to ::Tie_STDx.
Open a GitHub fork for ::Tie_STDx.
Package ::Sayfix and ::Tellfix as (one module? two modules?), together with appropriate POD, Build.PL, etc. and upload to CPAN.
Open a GitHub repo for the *fix modules.
Package the *fix modules together with those projects that depend upon them and make them part of their installations.
Other: ________

Note: Contents may change.

Comment on Dealing with IO::Capture bugs Select or Download Code

Replies are listed 'Best First'.
Re: Dealing with IO::Capture bugs by almut (Canon) on Aug 04, 2010 at 11:21 UTC
I'd favor 7. (as a short-term, low-profile solution).	[reply]
Re: Dealing with IO::Capture bugs by choroba (Cardinal) on Aug 04, 2010 at 10:56 UTC
Anything except 2. If he did not respond, you might just get an "I am no longer interested" anyway :)	[reply]
Re: Dealing with IO::Capture bugs by Your Mother (Archbishop) on Aug 04, 2010 at 17:10 UTC
Capture::Tiny seems quite lovely and well supported.	[reply]
Re: Dealing with IO::Capture bugs by Khen1950fx (Canon) on Aug 04, 2010 at 11:41 UTC
I'd go with (8). Other: throw in the towel, then try IO::Capture::Extended.	[reply]
Re^2: Dealing with IO::Capture bugs by Xiong (Hermit) on Aug 04, 2010 at 14:23 UTC
I now use `IO::Capture::Extended`, which is what provokes the dependency. Note: Contents may change.	[reply] [d/l]
Re: Dealing with IO::Capture bugs by Xiong (Hermit) on Dec 17, 2011 at 20:39 UTC
May as well note here: I've switched to the far more capable Test::Trap. So all IO::Capture* concerns are moot. Feste: Misprison in the highest degree. Lady, cucullus non facit monachum. That's as much to say as, I wear not motley in my brain....	[reply] [d/l]