Re: [RFC/PATCH 1/4] gitweb: Move subroutines to Gitweb::Config module

[Jakub Narebski <jnareb@gmail.com>]

On Sat, 12 Jun 2010, Ævar Arnfjörð Bjarmason wrote:
> On Sat, Jun 12, 2010 at 01:01, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Tue, 8 June 2010, Ævar Arnfjörð Bjarmason wrote:
>>
>>> I haven't contributed to Gitweb, nor do I have to deal with it. But
>>> I've followed this series and reviewed most of the Perl code in
>>> Git. Take these with a grain of salt.
>>>
>>> It would be very useful for the future of our Perl code if we had a
>>> dual-life system in Git. I.e. a cpan/ directory where we could drop
>>> CPAN modules that should be shipped with Git.
>>
>> The standard name for such directory is 'inc/', I think.
> 
> Perl itself uses cpan/, but Module::Install started the inc/. What we
> call it really doesn't matter though.

Right.

Although better example would be what modules on CPAN use, rather than
what Perl itself uses.

>>> Then we could just use e.g. Config::General (~3k lines of code)
>>> instead of writing our own config system. There are probably lots of
>>> wheels that we're inventing (and are going to invent) that have been
>>> done better elsewhere, with more testing.
>>
>> The problem with _optional_ Config::General config is that people
>> would have incompatibile gitweb config files, some using Config::General
>> syntax, some current configuration in Perl.
> 
> Isn't the current patch series the first attempt at config file
> support? I.e. it's always been editing the source until now.

Errr... no!

$ git blame -C -C -w -L/^our.*'GITWEB_CONFIG'/,+12 gitweb/gitweb.perl
shows that current config file in Perl (loaded using 'do $file') is
with gitweb since at least 2006-08-02.
 
> In any case, proper non-executable config file support could easily be
> made optional, hopefully with a transition the non-executable one.

I'm not sure if it would be easy to translate currently used gitweb
config files to non-executable file format.  I think that %feature
hash make it so such config format would have to support nested 
structures, which means e.g. JSON or YAML.

Besides how would you store / define $export_auth_hook in non-executable
file format?

  # show repository only if this subroutine returns true
  # when given the path to the project, for example:
  #    sub { return -e "$_[0]/git-daemon-export-ok"; }
  our $export_auth_hook = undef;

-- 
Jakub Narebski
Poland