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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jun 8, 2010, 13:50 UTC
Message-ID: <AANLkTimq-46ghYT6TqXn1AB0NQIobcDaufsSJ5AEFE5z@mail.gmail.com>
In-Reply-To: <201006081446.22587.jnareb@gmail.com>

2010/6/8 Jakub Narebski <jnareb@gmail.com>:

Show 24 quoted lines

> A few generic comments about this whole series.
> [...]
> Third, and I think most important, is that the whole splitting gitweb into
> modules series seems to alck direction, some underlying architecture
> design.  For example Gitweb::HTML, Gitweb::HTML::Link, Gitweb::HTML::String
> seems to me too detailed, too fine-grained modules.
>
> It was not visible at first, because Gitweb::Config, Gitweb::Request and to
> a bit lesser extent Gitweb::Git fell out naturally.  But should there be
> for example Gitweb::Escape module, or should its functionality be a part of
> Gitweb::Util?  Those issues needs to be addressed.  Perhaps they were
> discussed with this GSoC project mentors (via IRC, private email, IM), but
> we don't know what is the intended architecture design of gitweb.
>
> Should we try for Model-Viewer-Controller pattern without backing MVC
> (micro)framework?  (One of design decisions for gitweb was have it working
> out of the box if Perl and git are installed, without requiring to install
> extra modules; but now we can install extra Perl modules e.g. from CPAN
> under lib/...).  How should we organize gitweb code into packages
> (modules)?
>
> Perhaps having gitweb.perl, Gitweb::Git, Gitweb::Config, Gitweb::Request,
> Gitweb::Util and Gitweb would be enough?  Should it be Gitweb::HTML or
> Gitweb::View?  Etc., etc.,...

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.

We already do this in a less sophisticated way for Error.pm, is there any reason not to expand it to install more CPAN modules if they aren't present on the system? That'd allow us to use them, but still only depend on vanilla Perl.

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.

Unlike Python or Java, Perl's policy is for core modules is to only include those required to better bootstrap the CPAN toolchain. So if we continue sticking to core Perl our code is only going to drift further away from Perl best practices.