Re: [PATCH 8/9] gitweb: Convert output to using indirect file handle
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Jan 25, 2010, 21:48 UTC
- Message-ID
- <201001252248.14874.jnareb@gmail.com>
- In-Reply-To
- <4B5E03AD.1020404@eaglescrag.net>
On Mon, 25 Jan 2010, J.H. wrote:
Show 10 quoted lines
> > 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