Chromatic wrote:
On Mon, 2005-09-12 at 09:36 +1000, Adam Kennedy wrote:
If you do realize, but it takes you 3 days to update once mainline
was fixed, and it takes mainline 3 days to update once Joe Random's
patch was submitted, why should new users from these 3 days get a
buggy, outdated version when a better one is updated?
Because it was obviously good enough _already_ to allow the testing to
proceed successfully. And if it was a problem, well I would have updated
my dependency on that testing version to the current one, and when I
reroll the dist if fails, wanting the newer version.
I don't feel as confident as you do that if the tests all passed on your
machine that they'll automatically pass everywhere. Yuval's point about
bundling dependencies falling out of date elsewhere is pretty strong.
Of course they won't pass everywhere. If you run the tests on a
different platform where my code breaks, the tests fail. If you run the
tests of a different platform where the test module's code fails, my
code fails to, except possibly in a very limited number of cases where
the testing modules fails in such a way that it still returns the
correct results, including for the tests that would catch false
positives and false negatives.
And if it's passing for the entire test suite, is it really broken?
Regardless, what are your reasons for using Module::Install to create
distributable bundles? I'd like to understand more the problems it
addresses in hopes of trying to understand the real problems that
various users face.
Firstly, it's incredibly simple to write the Makefile.PL
-----------------------------------------------------------------------
use inc::Module::Install;
name ( 'Test-Inline' );
abstract ( 'Inlining your tests next to the code being tested' );
author ( 'Adam Kennedy<[EMAIL PROTECTED]>' );
version_from ( 'lib/Test/Inline.pm' );
requires ( 'perl' => '5.005' );
requires ( 'File::Spec' => '0.82' );
requires ( 'List::Util' => '1.11' );
requires ( 'File::Slurp' => '9999.04' );
requires ( 'File::Find::Rule' => '0.26' );
requires ( 'Algorithm::Dependency' => '1.02' );
requires ( 'Class::Autouse' => '1.15' );
requires ( 'File::Flat' => '0.95' );
requires ( 'Config::Tiny' => '2.00' );
requires ( 'Getopt::Long' => '2.34' );
build_requires ( 'Test::More' => '0.47' );
build_requires ( 'Test::ClassAPI' => '1.02' );
include ( 'ExtUtils::AutoInstall' );
include ( 'Test::ClassAPI' );
include ( 'Class::Inspector' );
install_script ( 'bin/inline2test' );
no_index ( directory => 't.data' );
auto_install();
&WriteAll;
----------------------------------------------------------------------
All the obvious things you do when installing packages (or at least,
pure Perl ones) have a simple entry that does the right things behind
the scenes for you.
Secondly, it actively reduces installation dependencies.
For example, note that Test::ClassAPI. It in no way needs to be
installed on the computer permanently. It just needs to be on there and
working while the tests are running. It doesn't do anything exotic, but
including it reduces the number of dependencies for the module, which is
a good thing for a number of different types of people.
There's no manual step involved. If a new version comes along, well then
the next time I release it gets it. If there an actual bug that is
causing a problem for my userbase, then I'll do an incremental release
so they have it.
If it's slightly out of date, so be it. If that doesn't hurt anyone,
then I'm ahead.
Thirdly, Module::Install takes care of the icky details for me. It works
(I'm told) with both make and Module::Build, so it avoids the situation
mentioned before of having to install Module::Build in order to install
a MakeMaker module (ugh).
It adds more smarts at packaging time, meaning both less maintenance
work for me, and less problems for the person installing.
And although I've never yet had to resort to adding "smarter" code to
the Module::Install scripts, I have that option if I ever really really
need it.
As for things getting out of date, well I already have a nearly
completely automated packaging system that just involves:
perl build_package.pl --install --commit --upload Perl-MinimumVersion
... and I have PPI-related plans to automate an incremental release, and
then plans to hook _that_ up to minicpan to allow for automated (or
nearly automated) incremental releases if things come up.
Adam K
