lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject [lucy-dev] Remaining CPAN module dependencies
Date Mon, 14 Mar 2011 00:28:06 GMT
Greets,

There are only a few remaining places in the Lucy code base where we depend on
CPAN modules with non-AL2.0-compatible licenses.

The benchmarking suite provides a module to run under Plucene, which is
Perl-licensed.  Since we know the results of benchmarking the last release of
Plucene (1.25) and Plucene is no longer being developed, there's no need for
us to perform ongoing benchmarking of Plucene.  All Plucene-related code
should simply be removed.

The file trunk/devel/bin/smoke.pl, which was contributed by Peter Karman,
relies upon at least 4 CPAN modules: since some of those have nested
dependencies on other CPAN distros, there are likely more that would need to
be installed in order for the script to work.

There are only c. 80 lines of code in smoke.pl; from my perspective, modifying
it to eliminate these dependencies is less work than ascertaining whether our
distribution of a file that uses these modules would be kosher.

    Path::Class - replace with File::Spec::Functions
    SVN::Class - replace with system()
    JSON::XS - replace with ini-style name=value conf file.
    Email::Stuff - replace with Net::SMTP

I'm happy to work up a patch.  The result will be a little less elegant, but
workable.

The last file is trunk/perl/t/612-leak-trace.t -- which has an optional
dependency on the Perl-licensed module Test::LeakTrace.  This is another Peter
Karman contribution; I haven't taken advantage of it myself.  I use our
test_valgrind build target for memory leak debugging -- but test_valgrind has
sometimes missed leaks of Perl data structures, so perhaps this test has
unique utility.

Unfortunately I can't think of a way to replace the Test::LeakTrace
dependency.  Peter, do you feel strongly enough about this test file to do the
research on whether we can ship it with Lucy?  My inclination would be to
remove it because unlike Parse::RecDescent and JSON::XS, Lucy can still build
and run without it -- but maybe we should investigate what it tells us first?

Marvin Humphrey


Mime
View raw message