On Tue, 22 Feb 2011, Ãvar ArnfjÃrà Bjarmason wrote: > On Mon, Feb 14, 2011 at 20:39, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > > This means that we are not able to use web (micro)framework, or use > > templating engine to create HTML instead of combination of CGI.pm > > methods and handcrafted HTML (worrying about proper escaping), or just > > use CGI::Cache or Plack::Middleware::Cache for adding output caching > > to gitweb. ÂThough if one wants web interface in Perl that uses web > > framework (and is supposedly backwards-compatible with gitweb URLs), > > there is always Gitalist which uses Catalyst web framework. > > > > On the other hand requiring non-core Perl modules means that gitweb > > installation would be harder. ÂWe can work around this issue if there > > are a few small such modules (e.g. using Exception::Class or > > HTTP::Exception as base class for gitweb error handling) by putting > > them in 'inc/' and installing local version if they are not present, > > like Git.pm does with local Error.pm module. ÂBut for microframework, > > or templating engine, or e.g. Plack (if we go the route to make gitweb > > PSGI application) this would be rather out of question. ÂAnyway, in > > any case gitweb would probably require more complicated build system > > than current one... but moving to e.g. ExtUtils::MakeMaker shouldn't > > be that hard (see how Git.pm does it, only we can require Perl 5.8.3 > > which has new enough EU::MM that supports DESTDIR). > > Why do you think that if we use larger modules these things would get > harder? I mean here that while it makes sense to bundle some version of required modules in e.g. 'gitweb/inc/' (or 'perl/inc/') in gitweb sources if there are few small self-contained modules (like e.g. Try::Tiny, or Capture::Tiny), I don't think that bloating git repository with Perl dependencies would be a good idea. Well, we could get them from CPAN during build if they are not present, and/or download them and include in generated tarball... > There's already applications on the CPAN which can do "fat > packing". I.e. you could use Plack, Catalyst, Template and whatever > else but run some make target to pack gitweb and all its dependencies > into a single file. > > Obviously it would be really big, and probably slow unless you ran it > as a fastcgi script. But that would be a tradeoff for making the > source easier to maintain. Well, I know of two such modules: App::FatPack and PAR... neither of which is in core. But the issue is not with installing or bundling modules when they are present, I think; we can always install modules alongside gitweb in 'lib/' subdirectory, even if you don't have admin rights to install those required modules system-wide. And there is also local::lib, though the problem is that it is web server user account that has to have path to Perl modules set up correctly. > But packing things like these is not a technical challange at all, and > probably way easier than reinventing the wheel each time you need some > small thing that's not in core, but is in a popular & well tested CPAN > module. Well, there already exists Gitalist, which is Perl web interface to git repositories, which uses Catalyst MVC web framework (and which purposedly is backwards compatible with gitweb URLs, though I am not sure about path_info-based ones). There is a question of balance (minimal dependencies or not reinventing the wheel) and choice (which of types of server to support: CGI, FastCGI, mod_perl, PSGI; what templating engine to use: Template Toolkit, Template::Xslate, Tenjin, Template::Declare / Markapl, Template::Semantic and HTML::Zoom, Template::Moustache; what framework or microframework to use: Mojolicus, Dancer, Web::Simple, Catalyst, Jifty, CGI::Application, Mason, etc.). -- 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