On Mon, 25 Jan 2010, J.H. wrote: > > So there is a bit of rule of preservation of difficulty at work. Either > > we have large patch adding explicit filehandle to all print statements > > 'print <sth> -> print $out <sth>' but simple code, or have smaller patch > > but complicated *STDOUT manipulation, or have small patch but rely on > > non-core CPAN modules present. > > I think depending in non-core CPAN modules is a really bad idea, and > will cause some concern and consternation with mainline distributions, > besides making it more complicated for users to get this up and running > quickly and easily. Note: the modules in question are Capture::Tiny or PerlIO::Util. Capture::Tiny is available as perl-Capture-Tiny RPM module for Fedora Core up from FC11 and in DAG repository, at least. First, installing non-core CPAN modules locally for user is very simple thanks to local::lib. After setup it is simply 'cpan -i PerlIO::Util', and PerlIO::Util gets installed locally, by default inside ~/perl5. Second, we can go the route that Git.pm did, namely include sources for extra modules (private-Error.pm in case of Git.pm) and install it if needed. With proper build system (Module::Install, Module::Build) it is even simpler with inc or inc::latest. And there is always PAR[1] if you want to have everything in one file. [1]: http://par.perl.org > While I agree there are other ways of handling this > I think just adding the filehandle to the print statements provides the > easiest cross section of usability and functionality for everything > involved. Well, manipulating *STDOUT shouldn't be, I think, much harder, although I guess it would need more care (so that e.g. "Generating..." page gets written to real STDOUT). -- Jakub Narebski Poland -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html