Re: The future of gitweb (long term goals)

[Jakub Narebski <jnareb@gmail.com>]

On Tue, 22 Feb 2011, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Feb 14, 2011 at 20:39, Jakub Narebski <jnareb@gmail.com> 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