On Sat, 17 Apr 2010, Sam Vilain wrote:
> On Fri, 2010-04-16 at 11:18 +0200, Jakub Narebski wrote:
> > 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.
Errr... how the above addresses "not being able to install Perl modules
that web server can use without help from sysadmin", or in other words
"not being able to tell web server where to find locally installed /
/ additional Perl modules"? If you can't set PERL5LIB for 'apache'
or 'web' or 'nobody' user, and you can't edit web server configuration
files...
Well, perhaps
use lib (grep { -d } split /:/, "++GITWEBPERLLIB++");
and associated change to gitweb/Makefile would help here.
> > 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.
Tatsuhiko Miyagawa addressed the issue of "2.5MB tarball". PSGI is
specification, Plack is utilities (and includes reference implementation).
Using PSGI / Plack / PSGI compatibile web framework would give us ability
to run gitweb on many web servers: CGI, FastCGI, mod_perl (all those via
adapters from Plack), mod_psgi, HTTP::Server::PSGI (included in Plack),...
and give us Test::Plack.
But not less important would be ability to use Plack middleware; for
example gitweb output caching could be as simple as
use Plack::Builder;
...
builder {
enable "Cache", ...
$app;
};
>
> 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.
Thanks for the research on those Perl web frameworks.
> The HTTP::Server::Simple::PSGI
> dependency should let it support the 'instaweb' case with pure perl.
Or HTTP::Server::PSGI from Plack.
> > 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...
Errr... isn't FindBin considered harmful, and current best practice is
using Self::Dir, or just
# __DIR__ is taken from Dir::Self __DIR__ fragment
sub __DIR__ () {
File::Spec->rel2abs(join '', (File::Spec->splitpath(__FILE__))[0, 1]);
}
use lib __DIR__ . '/lib';
And there is also App::FatPacker and PAR solution; pity that neither is
in core (well, for App::FatPacker it would be build time dependency only).
--
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