Re: [spf:guess,iffy] Re: "Integrated Web Client for git" GSoC proposal

[Sam Vilain <sam@vilain.net>]

On Fri, 2010-04-16 at 11:18 +0200, Jakub Narebski wrote: 
> > > gitweb was and is meant to be simple, easy to install git web interface
> > > (single script + some static files), with minimal dependencies outside
> > > Perl core, and running with as old Perl as feasible (good Unicode support
> > > is requirement that forces minimal Perl version).
> 
> By the way, is the above statement correct?  What should be the *goal*
> for gitweb?  Is it running on oldest Perl possible (which IIRC is Perl
> 5.8.6, because gitweb needs good Unicode support)?  Is it minimal 
> required non-core dependencies (core as of Perl 5.8.6)?  Is it being
> easy to install (single monolithic script + some minimal number of static
> files like CSS, JavaScript, images + perhaps extra files with optional
> features like output caching) by hand?  Is it being easy to configure
> by hand?
> 
> With local::lib it is easy to install Perl modules from CPAN locally
> (in home directory), so perhaps we could ease on minimal dependencies
> rule.  On the other hand gitweb is web app, and one would have to be
> able to configure web server to use locally installed Perl modules,
> which might be not possible; this swicthes the problem from "not being
> able to install Perl modules as non-root" to "not being able to install
> Perl modules that web server can use without help from sysadmin".

This is correct for XS modules, using DynaLoader to link in
arbitrary .so's may be restricted in a web server :).  But for pure Perl
modules it should be no problem.  Many modules have both XS and
Pure-Perl versions, for instance Template Toolkit has both and so is
suitable for this style of bundling.

> There exists very many web frameworks in Perl[1][2][3][4]: Catalyst
> (one of more popular, used by Gitalist), Jifty, CGI::Application (and
> its offshot Titanium), Mojolicus, Dancer, Squatting, Web::Simple,...
> 
> Nowadays many (all mentioned) of those web frameworks are either built
> on top of PSGI / Plack (Perl Superglue for Web Frameworks and Web Servers),
> or have PSGI / Plack adapter (see http://plackperl.org).  So another
> solution would be to use bare-bones Plack instead of CGI with help
> of CGI.pm, perhaps also using one of URI dispatchers[5][6].  Plack/PSGI
> looks like the future of Perl web scripting... but is currently quite new,
> at version 0.9930.

Ok so PSGI is the port of Python's WSGI to Perl.  Plack is the reference
implementation, and also quite heavy at 2.5MB tarball.

Titanium is an extension to CGI::Application and requires DBI for
instance.  That's probably not right.

Jifty, Mojolicious, will also have prohibitively difficult dependencies
for the run-anywhere case.

Squatting has a few XS dependencies, but perhaps they could be excised if
required.  Dancer however seems to stand out at only 94kB tarball, minimal
non-core dependencies and support for PSGI.  The HTTP::Server::Simple::PSGI
dependency should let it support the 'instaweb' case with pure perl.

> The trouble with splitting is installing split web script.  I have no
> idea how to do this in cross-webserver way, cross-distribution and
> cross-system way (the filesystem hierarchy used by web server may
> differ from distribution to distribution, and from operating system
> to operating system).

It should be possible for the script to figure out what filesystem path it
is being run from, perhaps find a local lib/ dir and then add that to @INC.
In shell scripts you just use FindBin, I don't know whether that is still
expected to work from eg mod_perl but there's bound to be a solution for
that.  So yeah I'd say just aim to ship lots of .pm files in a nearby dir
alongside the script...

Sam