From: Jakub Narebski <jnareb@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>,
git@vger.kernel.org, Christian Couder <chriscool@tuxfamily.org>,
Petr Baudis <pasky@ucw.cz>
Subject: Re: [RFC/PATCH 1/4] gitweb: Move subroutines to Gitweb::Config module
Date: Sat, 12 Jun 2010 03:01:34 +0200 [thread overview]
Message-ID: <201006120301.37931.jnareb@gmail.com> (raw)
In-Reply-To: <AANLkTimq-46ghYT6TqXn1AB0NQIobcDaufsSJ5AEFE5z@mail.gmail.com>
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.
There is for example 'inc::latest' module (unfortunately in core only
since latest Perl, i.e. version 5.12), which uses modules bundled in
'inc/' if they are newer than installed ones. It is in Module-Build
distribution.
BTW. it's a pity that PAR (Perl Archiving Toolkit, par.perl.org)
is not in core...
>
> 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.
Sidenote about Error.pm: from what I understand modern consensus is
that Error.pm was a failed approach, and currently recommended way to
use exceptions in Perl is via block form of eval, e.g. Try::Tiny or
TryCatch (this requires Moose and PPI), and not Error.
The Error documentation nowadays includes the following instructions:
WARNING
Using the "Error" module is no longer recommended due to the
black-magical nature of its syntactic sugar, which often tends to
break. Its maintainers have stopped actively writing code that uses
it, and discourage people from doing so. See the "SEE ALSO" section
below for better recommendations.
[...]
SEE ALSO
See Exception::Class for a different module providing Object-Oriented
exception handling, along with a convenient syntax for declaring
hierarchies for them. It doesn't provide Error's syntactic sugar of
'try { ... }, catch { ... }', etc. which may be a good thing or a bad
thing based on what you want. (Because Error's syntactic sugar tends
to break.)
Error::Exception aims to combine Error and Exception::Class "with
correct stringification".
TryCatch and Try::Tiny are similar in concept to Error.pm only
providing a syntax that hopefully breaks less.
>
> 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.
> 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.
Right.
Still, we don't want to require having half of CPAN in 'inc/' to
install gitweb. Perhaps "no non-core dependencies" is too strict,
and should be replaced by "minimal non-core depencencies".
--
Jakub Narebski
Poland
next prev parent reply other threads:[~2010-06-12 1:01 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-07 20:50 [RFC/PATCH 1/4] gitweb: Move subroutines to Gitweb::Config module Pavan Kumar Sunkara
2010-06-07 20:50 ` [RFC/PATCH 2/4] gitweb: Create Gitweb::HTML::Link module Pavan Kumar Sunkara
2010-06-07 20:50 ` [RFC/PATCH 3/4] gitweb: Create Gitweb::HTML module Pavan Kumar Sunkara
2010-06-07 20:50 ` [RFC/PATCH 4/4] gitweb: Create Gitweb::HTML::String module Pavan Kumar Sunkara
2010-06-07 20:58 ` Pavan Kumar Sunkara
2010-06-08 12:46 ` [RFC/PATCH 1/4] gitweb: Move subroutines to Gitweb::Config module Jakub Narebski
2010-06-08 13:50 ` Ævar Arnfjörð Bjarmason
2010-06-12 1:01 ` Jakub Narebski [this message]
2010-06-12 1:22 ` Ævar Arnfjörð Bjarmason
2010-06-12 1:41 ` Jakub Narebski
2010-06-08 14:13 ` Petr Baudis
2010-06-08 19:22 ` Pavan Kumar Sunkara
2010-06-08 19:55 ` Petr Baudis
2010-06-08 20:24 ` Pavan Kumar Sunkara
2010-06-08 20:50 ` Petr Baudis
2010-06-08 23:38 ` Jakub Narebski
2010-06-09 13:13 ` Jakub Narebski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201006120301.37931.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=avarab@gmail.com \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=pasky@ucw.cz \
--cc=pavan.sss1991@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).