{"thread":{"id":"23490","subject":"Re: [spf:guess,iffy] Re: \"Integrated Web Client for git\" GSoC proposal","startedAt":"2010-04-16T09:18:30Z","lastAt":"2010-04-17T12:53:09Z","messageCount":8,"participants":["Jakub Narebski","Sam Vilain","Tatsuhiko Miyagawa","Pavan Kumar Sunkara"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"139661","messageId":"201004161118.32163.jnareb@gmail.com","threadId":"23490","inReplyTo":"1271293123.6248.147.camel@denix","subject":"Re: [spf:guess,iffy] Re: \"Integrated Web Client for git\" GSoC proposal","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-16T09:18:30Z","receivedAt":"2010-04-16T09:18:30Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Thu, 15 April 2010, Sam Vilain wrote:\n> On Thu, 2010-04-15 at 02:04 +0200, Jakub Narebski wrote:\n\n> > gitweb was and is meant to be simple, easy to install git web interface\n> > (single script + some static files), with minimal dependencies outside\n> > Perl core, and running with as old Perl as feasible (good Unicode support\n> > is requirement that forces minimal Perl version).\n\nBy the way, is the above statement correct?  What should be the *goal*\nfor gitweb?  Is it running on oldest Perl possible (which IIRC is Perl\n5.8.6, because gitweb needs good Unicode support)?  Is it minimal \nrequired non-core dependencies (core as of Perl 5.8.6)?  Is it being\neasy to install (single monolithic script + some minimal number of static\nfiles like CSS, JavaScript, images + perhaps extra files with optional\nfeatures like output caching) by hand?  Is it being easy to configure\nby hand?\n\nWith local::lib it is easy to install Perl modules from CPAN locally\n(in home directory), so perhaps we could ease on minimal dependencies\nrule.  On the other hand gitweb is web app, and one would have to be\nable to configure web server to use locally installed Perl modules,\nwhich might be not possible; this swicthes the problem from \"not being\nable to install Perl modules as non-root\" to \"not being able to install\nPerl modules that web server can use without help from sysadmin\".\n\n\nOne of requirements is backwards compatibility of gitweb links (URLs),\nboth query string based, and path_info URLs.  Yet another is ability\nto *scan* for projects (this is IIRC requirement for git.kernel.org),\nrather than using project index file (perhaps (re)generated \n(semi)automatically).\n\n> > \n> > Gitalist requires Catalyst web framework, which while it is (one of)\n> > modern Perl web frameworks is not exactly lightweight.\n> \n> Ok, I just re-checked the dependencies and my assertion that a pure-perl\n> Gitalist would be possible is indeed wrong.  It certainly is though with\n> very lightweight frameworks like CGI::Application.  If you are splitting\n> the script up, all the best to you, but please do consider something\n> like that rather than re-inventing the wheel!\n\nThere exists very many web frameworks in Perl[1][2][3][4]: Catalyst\n(one of more popular, used by Gitalist), Jifty, CGI::Application (and\nits offshot Titanium), Mojolicus, Dancer, Squatting, Web::Simple,...\n\nNowadays many (all mentioned) of those web frameworks are either built\non top of PSGI / Plack (Perl Superglue for Web Frameworks and Web Servers),\nor have PSGI / Plack adapter (see http://plackperl.org).  So another\nsolution would be to use bare-bones Plack instead of CGI with help\nof CGI.pm, perhaps also using one of URI dispatchers[5][6].  Plack/PSGI\nlooks like the future of Perl web scripting... but is currently quite new,\nat version 0.9930.\n\n[1]: http://www.perlfoundation.org/perl5/index.cgi?web_frameworks\n[2]: http://plackperl.org/ (\"Frameworks\" section)\n[3]: http://perl.worldken.org/search?q=web+framework\n[4]: http://search.cpan.org/search?query=web+framework&mode=all\n\n[5]: http://www.perlfoundation.org/perl5/index.cgi?web_application_dispatchers\n[6]: http://github.com/miyagawa/plack-dispatching-samples\n\n\nAs to splitting gitweb into smaller modules (like e.g. SVN::Web)...\nGitweb isn't the largest script in git sources: gitk is.  But splitting\ngitk should be much easier - git-gui is already split.  Close after\ngitweb is git-svn, which probably also need splitting; and again it\nwould be easier to split parts of git-svn e.g into Git::SVN module,\nas git-svn already depends on Git.pm.\n\nThe trouble with splitting is installing split web script.  I have no\nidea how to do this in cross-webserver way, cross-distribution and\ncross-system way (the filesystem hierarchy used by web server may\ndiffer from distribution to distribution, and from operating system\nto operating system).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"139664","messageId":"201004161503.34991.jnareb@gmail.com","threadId":"23490","inReplyTo":"7vvdbuqh2c.fsf@alter.siamese.dyndns.org","subject":"Re: \"Integrated Web Client for git\" GSoC proposal","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-16T13:03:31Z","receivedAt":"2010-04-16T13:03:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia środa 14. kwietnia 2010 15:50, Junio C Hamano napisał:\n> Petr Baudis <pasky@ucw.cz> writes:\n> \n> > Well, it's not that noone maintains gitweb or noone reviews patches;\n> > smaller changes do get merged relatively fine (I'd hope), but larger\n> > changes get sidetracked in endless discussions and perpetual polishing.\n> >\n> > I think the problem is that we are extremely perfectionistic about\n> > whatever gets into gitweb ...\n> \n> Hmph, from time to time, I found review comments that were too picky, but\n> I don't think gitweb reviews are particularly \"perfectionistic\".\n> \n> What I find is more problematic is the lack of post-review follow up,\n> especially when the submitter disappears without responding to the\n> reviews.  To patches that are in the core-git area, I find myself doing\n> the \"finishing touches\" in such a case if/when the topic deserves it.\n> What gitweb needs may a dedicated shepherd or two.\n> \n> > ... but other than that I think gitweb just\n> > needs more of the \"best is the enemy of good\" mentality.\n> \n> If that means I'd see more \"These are a resend of the good enough version\n> of patches with our Acks; apply them\" from you and/or Jakub, or \"In this\n> repository, we have queued the good ones---pull them\", which is even\n> better, I am all for it ;-).\n\nWell, I try to either save interesting gitweb patches (which doesn't help\nmuch), or import them to my repository at\n  http://repo.or.cz/w/git/jnareb-git.git\n\nThe interesting branches would be gitwe/* branches.  Some of them are\nregularly rebased against 'master' branch of main git repository.\n\nThose branches are:\n\ngitweb/web::\n\n  The branch that I am doing miscelanous gitweb development on.  Managed\n  using StGit, not all patches applied (visible).  Regularly rebased \n  against 'origin' branch.\n\n  Currently contains syntax highlighting support from Johannes Schindelin\n  (based in turn on Daniel Svensson's and Sham Chukoury's work in\n  gitweb-xmms2.git), plus my refactoring of that.\n\n  Needs decision on names of subroutines, and on semantics of 'highlight'\n  feature (on/off, or highlighter name).\n\ngitweb/cache-kernel-pu::\n\n  Simple file-based output caching for gitweb, based on work by John \n  'Warthog9' Hawley (J.H.), split into smaller patches for easier review.\n  Much more configurable than original patch(es) by J.H., with pluggable\n  caching engine (it works for example with Cache::FileCache).\n\n  J.H. ideas were: no serialization and mtime based expiration of simple\n  file-based cache, using locking to avoid 'cache miss stampede' problem,\n  serving stale data when cache entry is being regenerated, generating\n  cache in background, trick for non-AJAXy progress info, having everything\n  related to cache in 'cache.pm' file.\n\n  My ideas were: tests, separating simple file-based cache into separate\n  package and making it easy to replace this cache engine by any\n  Cache::Cache or CHI cache driver, select(FILEHANLE) based capturing,\n  separating capturing output into package to be able to replace it by\n  other captyring mechanism, daemonizing for background cache generation\n  (for mod_perl), being able to 'require' the 'cache.pm' file, gathering\n  options in %cache_options and adding configurability, documentation.\n\n  This is work in progress, and a bit of mess currently.  I have posted\n  information about current state of this branch to git mailing list.\n\n  Rebased on top of 'origin'.\n\ngitweb/cache-kernel-v3::\ngitweb/cache-kernel-v2::\ngitweb/cache-kernel::\n\n  Gitweb caching series, as send to git mailing list.  Not modified, here\n  for historical reasons.\n\ngitweb/category::\n\n  The \"nitpicked to death\" series by Sebastien Cevey.\n\n  I have meant to fix the way list of projects is displayed first, to\n  separate filtering list of projects and printing list of projects,\n  but never did managed to get to it.\n\n  Rebased on top of 'origin'.  Series is stalled.\n\ngitweb/committags::\n\n  Series by Marcel M. Cary.\n\n  I have meant to comment on this series, but forgot about it.  The major\n  problem is deciding how to configure this feature... and how to name it.\n  It is decision about API (configuration), so it is important to get it\n  right the first time.\n\n  Needs review.  Series is stalled.\n\ngitweb/cache::\n\n  Old caching (pre-GSoC2009 gitweb caching project even) of Perl data,\n  for projects_list page only, by Petr Baudis.  Some version of it might\n  be used on http://repo.or.cz\n\n  Abandoned for now.  Needs checking which method of caching is better.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"139713","messageId":"1271473792.3506.30.camel@denix","threadId":"23490","inReplyTo":"201004161118.32163.jnareb@gmail.com","subject":"Re: [spf:guess,iffy] Re: \"Integrated Web Client for git\" GSoC proposal","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2010-04-17T03:09:52Z","receivedAt":"2010-04-17T03:09:52Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Fri, 2010-04-16 at 11:18 +0200, Jakub Narebski wrote: \n> > > gitweb was and is meant to be simple, easy to install git web interface\n> > > (single script + some static files), with minimal dependencies outside\n> > > Perl core, and running with as old Perl as feasible (good Unicode support\n> > > is requirement that forces minimal Perl version).\n> \n> By the way, is the above statement correct?  What should be the *goal*\n> for gitweb?  Is it running on oldest Perl possible (which IIRC is Perl\n> 5.8.6, because gitweb needs good Unicode support)?  Is it minimal \n> required non-core dependencies (core as of Perl 5.8.6)?  Is it being\n> easy to install (single monolithic script + some minimal number of static\n> files like CSS, JavaScript, images + perhaps extra files with optional\n> features like output caching) by hand?  Is it being easy to configure\n> by hand?\n> \n> With local::lib it is easy to install Perl modules from CPAN locally\n> (in home directory), so perhaps we could ease on minimal dependencies\n> rule.  On the other hand gitweb is web app, and one would have to be\n> able to configure web server to use locally installed Perl modules,\n> which might be not possible; this swicthes the problem from \"not being\n> able to install Perl modules as non-root\" to \"not being able to install\n> Perl modules that web server can use without help from sysadmin\".\n\nThis is correct for XS modules, using DynaLoader to link in\narbitrary .so's may be restricted in a web server :).  But for pure Perl\nmodules it should be no problem.  Many modules have both XS and\nPure-Perl versions, for instance Template Toolkit has both and so is\nsuitable for this style of bundling.\n\n> There exists very many web frameworks in Perl[1][2][3][4]: Catalyst\n> (one of more popular, used by Gitalist), Jifty, CGI::Application (and\n> its offshot Titanium), Mojolicus, Dancer, Squatting, Web::Simple,...\n> \n> Nowadays many (all mentioned) of those web frameworks are either built\n> on top of PSGI / Plack (Perl Superglue for Web Frameworks and Web Servers),\n> or have PSGI / Plack adapter (see http://plackperl.org).  So another\n> solution would be to use bare-bones Plack instead of CGI with help\n> of CGI.pm, perhaps also using one of URI dispatchers[5][6].  Plack/PSGI\n> looks like the future of Perl web scripting... but is currently quite new,\n> at version 0.9930.\n\nOk so PSGI is the port of Python's WSGI to Perl.  Plack is the reference\nimplementation, and also quite heavy at 2.5MB tarball.\n\nTitanium is an extension to CGI::Application and requires DBI for\ninstance.  That's probably not right.\n\nJifty, Mojolicious, will also have prohibitively difficult dependencies\nfor the run-anywhere case.\n\nSquatting has a few XS dependencies, but perhaps they could be excised if\nrequired.  Dancer however seems to stand out at only 94kB tarball, minimal\nnon-core dependencies and support for PSGI.  The HTTP::Server::Simple::PSGI\ndependency should let it support the 'instaweb' case with pure perl.\n\n> The trouble with splitting is installing split web script.  I have no\n> idea how to do this in cross-webserver way, cross-distribution and\n> cross-system way (the filesystem hierarchy used by web server may\n> differ from distribution to distribution, and from operating system\n> to operating system).\n\nIt should be possible for the script to figure out what filesystem path it\nis being run from, perhaps find a local lib/ dir and then add that to @INC.\nIn shell scripts you just use FindBin, I don't know whether that is still\nexpected to work from eg mod_perl but there's bound to be a solution for\nthat.  So yeah I'd say just aim to ship lots of .pm files in a nearby dir\nalongside the script...\n\nSam\n"},{"id":"139717","messageId":"loom.20100417T081957-371@post.gmane.org","threadId":"23490","inReplyTo":"1271473792.3506.30.camel@denix","subject":"Re: [spf:guess,iffy] Re: \"Integrated Web Client for git\" GSoC proposal","fromName":"Tatsuhiko Miyagawa","fromEmail":"miyagawa@bulknews.net","sentAt":"2010-04-17T06:27:16Z","receivedAt":"2010-04-17T06:27:16Z","isPatch":false,"sender":{"key":"miyagawa@bulknews.net","avatar":null},"body":"Sam Vilain <sam <at> vilain.net> writes:\n\n> > of CGI.pm, perhaps also using one of URI dispatchers[5][6].  Plack/PSGI\n> > looks like the future of Perl web scripting... but is currently quite new,\n> > at version 0.9930.\n\nI admit that it's quite new - not old anyway, but don't get fooled by its\nversion number. It's already adapted by almost all perl frameworks and\nused by lots of companies on production.\n \n> Ok so PSGI is the port of Python's WSGI to Perl.  Plack is the reference\n> implementation, and also quite heavy at 2.5MB tarball.\n\nNo, the tarball just contains 2.4MB of .jpeg file for large-file download\nand upload testing. Its  dependencies are kept minimal - only requires\nLWP, URI and some pure perl modules.\n\n> required.  Dancer however seems to stand out at only 94kB tarball, minimal\n> non-core dependencies and support for PSGI.  The HTTP::Server::Simple::PSGI\n> dependency should let it support the 'instaweb' case with pure perl.\n\nYou can already use CGI::Emulate::PSGI (via Plack::App::CGIBin) to run\ngitweb.cgi on Plack, or whatever web server that supports PSGI - like\nHTTP::Server::Simple::PSGI you just mentioned.\nhttp://gist.github.com/346068\n\n> It should be possible for the script to figure out what filesystem path it\n> is being run from, perhaps find a local lib/ dir and then add that to @INC.\n> In shell scripts you just use FindBin, I don't know whether that is still\n> expected to work from eg mod_perl but there's bound to be a solution for\n> that.  So yeah I'd say just aim to ship lots of .pm files in a nearby dir\n> alongside the script...\n\nOr use App::FatPacker.\n\n--\nTatsuhiko Miyagawa\n"},{"id":"139721","messageId":"p2ue72faaa81004170022q2fc3a490u83ad6e325b91e139@mail.gmail.com","threadId":"23490","inReplyTo":"r2we72faaa81004170021z9920e6e9k4c3aa06fe46431b0@mail.gmail.com","subject":"Fwd: Re: \"Integrated Web Client for git\" GSoC proposal","fromName":"Pavan Kumar Sunkara","fromEmail":"pavan.sss1991@gmail.com","sentAt":"2010-04-17T07:22:52Z","receivedAt":"2010-04-17T07:22:52Z","isPatch":false,"sender":{"key":"pavan.sss1991@gmail.com","avatar":"https://avatars.githubusercontent.com/u/174703?v=4"},"body":"On Sat, Apr 17, 2010 at 11:57 AM, Tatsuhiko Miyagawa\n<miyagawa@bulknews.net> wrote:\n>\n> Sam Vilain <sam <at> vilain.net> writes:\n>\n> > > of CGI.pm, perhaps also using one of URI dispatchers[5][6].  Plack/PSGI\n> > > looks like the future of Perl web scripting... but is currently quite new,\n> > > at version 0.9930.\n>\n> I admit that it's quite new - not old anyway, but don't get fooled by its\n> version number. It's already adapted by almost all perl frameworks and\n> used by lots of companies on production.\n>\n> > Ok so PSGI is the port of Python's WSGI to Perl.  Plack is the reference\n> > implementation, and also quite heavy at 2.5MB tarball.\n>\n> No, the tarball just contains 2.4MB of .jpeg file for large-file download\n> and upload testing. Its  dependencies are kept minimal - only requires\n> LWP, URI and some pure perl modules.\n>\n> > required.  Dancer however seems to stand out at only 94kB tarball, minimal\n> > non-core dependencies and support for PSGI.  The HTTP::Server::Simple::PSGI\n> > dependency should let it support the 'instaweb' case with pure perl.\n>\n> You can already use CGI::Emulate::PSGI (via Plack::App::CGIBin) to run\n> gitweb.cgi on Plack, or whatever web server that supports PSGI - like\n> HTTP::Server::Simple::PSGI you just mentioned.\n> http://gist.github.com/346068\n>\n> > It should be possible for the script to figure out what filesystem path it\n> > is being run from, perhaps find a local lib/ dir and then add that to @INC.\n> > In shell scripts you just use FindBin, I don't know whether that is still\n> > expected to work from eg mod_perl but there's bound to be a solution for\n> > that.  So yeah I'd say just aim to ship lots of .pm files in a nearby dir\n> > alongside the script...\n>\n> Or use App::FatPacker.\n>\n> --\n> Tatsuhiko Miyagawa\n>\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n\nWe need to keep gitweb dependancies as less as possible. So, using\nframeworks will be a bad idea, as everybody might don't want to use\nthem.\n\nComing to splitting of gitweb, as Jakub said installing a split web\nscript would be a problem, but we can have a solution the problem by\nusing proper algorithms. First, we parse the URL and get to know which\nfunction to be implemented and then we include the necessary file and\ncall the function which will then execute and return the proper HTML\noutput.\n\nThis way, we can no longer worry about installing the split webscript.\nAll we need is to install the basic gitweb.pl file which does all this\nbasic parsing and calling other perl files. The other files just\nneeded to be in the path.\n\n-pavan\n"},{"id":"139729","messageId":"201004171154.38988.jnareb@gmail.com","threadId":"23490","inReplyTo":"1271473792.3506.30.camel@denix","subject":"Re: [spf:guess,iffy] Re: \"Integrated Web Client for git\" GSoC proposal","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-17T09:54:36Z","receivedAt":"2010-04-17T09:54:36Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sat, 17 Apr 2010, Sam Vilain wrote:\n> On Fri, 2010-04-16 at 11:18 +0200, Jakub Narebski wrote: \n\n> > With local::lib it is easy to install Perl modules from CPAN locally\n> > (in home directory), so perhaps we could ease on minimal dependencies\n> > rule.  On the other hand gitweb is web app, and one would have to be\n> > able to configure web server to use locally installed Perl modules,\n> > which might be not possible; this swicthes the problem from \"not being\n> > able to install Perl modules as non-root\" to \"not being able to install\n> > Perl modules that web server can use without help from sysadmin\".\n> \n> This is correct for XS modules, using DynaLoader to link in\n> arbitrary .so's may be restricted in a web server :).  But for pure Perl\n> modules it should be no problem.  Many modules have both XS and\n> Pure-Perl versions, for instance Template Toolkit has both and so is\n> suitable for this style of bundling.\n\nErrr... how the above addresses \"not being able to install Perl modules\nthat web server can use without help from sysadmin\", or in other words\n\"not being able to tell web server where to find locally installed /\n/ additional Perl modules\"?  If you can't set PERL5LIB for 'apache'\nor 'web' or 'nobody' user, and you can't edit web server configuration\nfiles...\n\nWell, perhaps\n\n  use lib (grep { -d } split /:/, \"++GITWEBPERLLIB++\");\n\nand associated change to gitweb/Makefile would help here.\n\n> > There exists very many web frameworks in Perl[1][2][3][4]: Catalyst\n> > (one of more popular, used by Gitalist), Jifty, CGI::Application (and\n> > its offshot Titanium), Mojolicus, Dancer, Squatting, Web::Simple,...\n> > \n> > Nowadays many (all mentioned) of those web frameworks are either built\n> > on top of PSGI / Plack (Perl Superglue for Web Frameworks and Web Servers),\n> > or have PSGI / Plack adapter (see http://plackperl.org).  So another\n> > solution would be to use bare-bones Plack instead of CGI with help\n> > of CGI.pm, perhaps also using one of URI dispatchers[5][6].  Plack/PSGI\n> > looks like the future of Perl web scripting... but is currently quite new,\n> > at version 0.9930.\n> \n> Ok so PSGI is the port of Python's WSGI to Perl.  Plack is the reference\n> implementation, and also quite heavy at 2.5MB tarball.\n\nTatsuhiko Miyagawa addressed the issue of \"2.5MB tarball\".  PSGI is\nspecification, Plack is utilities (and includes reference implementation).\n\nUsing PSGI / Plack / PSGI compatibile web framework would give us ability\nto run gitweb on many web servers: CGI, FastCGI, mod_perl (all those via\nadapters from Plack), mod_psgi, HTTP::Server::PSGI (included in Plack),...\nand give us Test::Plack.\n\nBut not less important would be ability to use Plack middleware; for\nexample gitweb output caching could be as simple as\n\n  use Plack::Builder;\n  ...\n\n  builder {\n     enable \"Cache\", ...\n     $app;\n  };\n\n> \n> Titanium is an extension to CGI::Application and requires DBI for\n> instance.  That's probably not right.\n> \n> Jifty, Mojolicious, will also have prohibitively difficult dependencies\n> for the run-anywhere case.\n> \n> Squatting has a few XS dependencies, but perhaps they could be excised if\n> required.  Dancer however seems to stand out at only 94kB tarball, minimal\n> non-core dependencies and support for PSGI.  \n\nThanks for the research on those Perl web frameworks.\n\n> The HTTP::Server::Simple::PSGI \n> dependency should let it support the 'instaweb' case with pure perl.\n\nOr HTTP::Server::PSGI from Plack.\n\n> > The trouble with splitting is installing split web script.  I have no\n> > idea how to do this in cross-webserver way, cross-distribution and\n> > cross-system way (the filesystem hierarchy used by web server may\n> > differ from distribution to distribution, and from operating system\n> > to operating system).\n> \n> It should be possible for the script to figure out what filesystem path it\n> is being run from, perhaps find a local lib/ dir and then add that to @INC.\n> In shell scripts you just use FindBin, I don't know whether that is still\n> expected to work from eg mod_perl but there's bound to be a solution for\n> that.  So yeah I'd say just aim to ship lots of .pm files in a nearby dir\n> alongside the script...\n\nErrr... isn't FindBin considered harmful, and current best practice is\nusing Self::Dir, or just\n\n        # __DIR__ is taken from Dir::Self __DIR__ fragment\n        sub __DIR__ () {\n                File::Spec->rel2abs(join '', (File::Spec->splitpath(__FILE__))[0, 1]);\n        }\n        use lib __DIR__ . '/lib';\n\n\nAnd there is also App::FatPacker and PAR solution; pity that neither is\nin core (well, for App::FatPacker it would be build time dependency only).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"139744","messageId":"m3vdbqdz1b.fsf@localhost.localdomain","threadId":"23490","inReplyTo":"loom.20100417T081957-371@post.gmane.org","subject":"Re: [spf:guess,iffy] Re: \"Integrated Web Client for git\" GSoC proposal","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-17T12:50:57Z","receivedAt":"2010-04-17T12:50:57Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Restored some of Cc list...\n\nTatsuhiko Miyagawa <miyagawa@bulknews.net> writes:\n\n> Sam Vilain <sam <at> vilain.net> writes:\n\n> > It should be possible for the script to figure out what filesystem path it\n> > is being run from, perhaps find a local lib/ dir and then add that to @INC.\n\nFindBin, Dir::Self (or just relevant code from it), and then \"use lib <dir>\".\n\n> > In shell scripts you just use FindBin, I don't know whether that is still\n> > expected to work from eg mod_perl but there's bound to be a solution for\n> > that.  So yeah I'd say just aim to ship lots of .pm files in a nearby dir\n> > alongside the script...\n> \n> Or use App::FatPacker.\n\nBut try to make this build-time dependency optional.  I wonder also\nwhat is performance cost of using App::FatPacker trick.\n\n\nIt is a bit pity that PAR is not in core.  We could use \n\n  $ git archive --format=zip --output=gitweb.par --prefix=lib/ \\\n    HEAD -- gitweb/lib\n\nto generate packfile, and then\n\n  use PAR 'gitweb.par';\n\nin gitweb.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"139745","messageId":"m3r5medyw9.fsf@localhost.localdomain","threadId":"23490","inReplyTo":"p2ue72faaa81004170022q2fc3a490u83ad6e325b91e139@mail.gmail.com","subject":"Re: Fwd: Re: \"Integrated Web Client for git\" GSoC proposal","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-17T12:53:09Z","receivedAt":"2010-04-17T12:53:09Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Pavan Kumar Sunkara <pavan.sss1991@gmail.com> writes:\n\n> We need to keep gitweb dependancies as less as possible. So, using\n> frameworks will be a bad idea, as everybody might don't want to use\n> them.\n\nWell, hopefully in the future PSGI / Plack would be as widely\navailable as CGI.pm is currently...\n\n> \n> Coming to splitting of gitweb, as Jakub said installing a split web\n> script would be a problem, but we can have a solution the problem by\n> using proper algorithms. First, we parse the URL and get to know which\n> function to be implemented and then we include the necessary file and\n> call the function which will then execute and return the proper HTML\n> output.\n> \n> This way, we can no longer worry about installing the split webscript.\n> All we need is to install the basic gitweb.pl file which does all this\n> basic parsing and calling other perl files. The other files just\n> needed to be in the path.\n\nNot a solution, I think.  If you could munge PATH for web server\n[user], you could munge PERL5LIB and use locally (local::lib)\ninstalled packages.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"}]}