Re: The future of gitweb (long term goals)

On Tue, 22 Feb 2011, Ævar Arnfjörð Bjarmason wrote:

On Mon, Feb 14, 2011 at 20:39, Jakub Narebski [off-list ref] wrote:

quoted

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