Bug #83340 for DBIx-Class: Test that DBIC Modules Load

Fri Feb 15 06:55:08 2013 dperrett [...] cambridge.org - Ticket created

Subject:	Test that DBIC Modules Load
Date:	Fri, 15 Feb 2013 11:54:54 +0000
To:	bug-DBIx-Class [...] rt.cpan.org
From:	Daniel Perrett <dperrett [...] cambridge.org>

BACKGROUND I installed DBIx::Class 0.08123 on Strawberry perl 5.12.3 using ppm (OS: XP Pro). The install was successful, but, while trying to run a minimal app (attached), DBIx::Class failed with this message: Can't locate Carp/Clan.pm in @INC (@INC contains: AudioDB/lib C:/strawberry/perl/site/lib C:/strawberry/perl/vendor/lib C:/strawberry/perl/lib .) at C:/strawberry/perl/site/lib/DBIx/Class/Exception.pm line 6. BEGIN failed--compilation aborted at C:/strawberry/perl/site/lib/DBIx/Class/Exception.pm line 6. Compilation failed in require at C:/strawberry/perl/site/lib/DBIx/Class/Schema.pm line 6. BEGIN failed--compilation aborted at C:/strawberry/perl/site/lib/DBIx/Class/Schema.pm line 6. Compilation failed in require at (eval 2) line 2. ...propagated at C:/strawberry/perl/lib/base.pm line 94. BEGIN failed--compilation aborted at AudioDB/lib/AudioDB/Schema.pm line 4. Compilation failed in require at adb-test.pl line 5. BEGIN failed--compilation aborted at adb-test.pl line 5. DBIx/Class/Exception.pm does indeed call Carp::Clan on line 6. I'm sure I can fix it by installing Carp::Clan, but I presume it ought to have gone in the DBIx::Class dependencies, as it's not a core module. DBIx::Class has now switched to a home-grown solution. I'm now upgrading using CPAN instead of ppm and have filed a bug with Strawberry separately to get a better DBIx::Class version. ACTION REQUESTED However, oddly, I also couldn't find any tests that guaranteed all the classes could be loaded ok, but the test suite is pretty big, so possibly I missed them. Nevertheless, clearly 0.8123 passed on a lot of machines, and where it failed, didn't necessarily say anything about Carp::Clan. Should such a test be included, if it is not already? Daniel

Download DBIx-Class-Requires-Carp-Clan.zip
application/zip 2.1k

Message body not shown because it is not plain text.

Fri Feb 15 07:14:51 2013 ribasushi [...] leporine.io - Correspondence added

Subject:	Re: [rt.cpan.org #83340] Test that DBIC Modules Load
Date:	Fri, 15 Feb 2013 23:14:19 +1100
To:	Daniel Perrett via RT <bug-DBIx-Class [...] rt.cpan.org>
From:	Peter Rabbitson <ribasushi [...] cpan.org>

On Fri, Feb 15, 2013 at 06:55:12AM -0500, Daniel Perrett via RT wrote: Show quoted text

> Fri Feb 15 06:55:08 2013: Request 83340 was acted upon. > Transaction: Ticket created by dperrett@cambridge.org > Queue: DBIx-Class > Subject: Test that DBIC Modules Load > Broken in: (no value) > Severity: (no value) > Owner: Nobody > Requestors: dperrett@cambridge.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83340 > > > > BACKGROUND > > I installed DBIx::Class 0.08123 on Strawberry perl 5.12.3 using ppm (OS: > XP Pro). The install was successful, but, while trying to run a minimal > app (attached), DBIx::Class failed with this message: > > Can't locate Carp/Clan.pm in @INC (@INC contains: AudioDB/lib > ... > > > However, oddly, I also couldn't find any tests that guaranteed all the > classes could be loaded ok, but the test suite is pretty big, so possibly > I missed them. Nevertheless, clearly 0.8123 passed on a lot of machines, > and where it failed, didn't necessarily say anything about Carp::Clan. > > Should such a test be included, if it is not already? >

Not really. DBIx::Class 0.08123 clearly indicates it requires Carp::Clan [1]. Having tests that verify that the necessary modules were indeed loaded is rather superfluous, because the impact of a broken toolchain is immediately apparent (as you saw). All in all whoever built the ppm screwed up royally, and it was not immediately apparent to you because ppm installs do not execute any tests. This is why it is always preferred to use the CPAN toolchain (cpan/cpanm/cpanp) as opposed to ppm. I will wait for you to confirm the above fully answers your question before closing this ticket. Cheers [1] https://metacpan.org/source/FREW/DBIx-Class-0.08123/META.yml#L34

Fri Feb 15 07:14:54 2013 The RT System itself - Status changed from 'new' to 'open'

Fri Feb 15 07:28:56 2013 dperrett [...] cambridge.org - Correspondence added

Subject:	Re: [rt.cpan.org #83340] Test that DBIC Modules Load
Date:	Fri, 15 Feb 2013 12:28:32 +0000
To:	bug-DBIx-Class [...] rt.cpan.org
From:	Daniel Perrett <dperrett [...] cambridge.org>

Thanks for the advice that best practice is to use cpan in the first instance instead of ppm: I'll do that in future. "Having tests that verify that the necessary modules were indeed loaded is rather superfluous" I agree loading the dependencies is redundant. I meant something like use_ok('DBIx::Class::Exception'), as distinct from duck-testing (if you know what I mean) the functionality of the module. Daniel From: "Peter Rabbitson via RT" <bug-DBIx-Class@rt.cpan.org> To: dperrett@cambridge.org Date: 15/02/2013 12:15 Subject: Re: [rt.cpan.org #83340] Test that DBIC Modules Load <URL: https://rt.cpan.org/Ticket/Display.html?id=83340 > On Fri, Feb 15, 2013 at 06:55:12AM -0500, Daniel Perrett via RT wrote: Show quoted text

> Fri Feb 15 06:55:08 2013: Request 83340 was acted upon. > Transaction: Ticket created by dperrett@cambridge.org > Queue: DBIx-Class > Subject: Test that DBIC Modules Load > Broken in: (no value) > Severity: (no value) > Owner: Nobody > Requestors: dperrett@cambridge.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83340 > > > > BACKGROUND > > I installed DBIx::Class 0.08123 on Strawberry perl 5.12.3 using ppm (OS:

Show quoted text

> XP Pro). The install was successful, but, while trying to run a minimal > app (attached), DBIx::Class failed with this message: > > Can't locate Carp/Clan.pm in @INC (@INC contains: AudioDB/lib > ... > > > However, oddly, I also couldn't find any tests that guaranteed all the > classes could be loaded ok, but the test suite is pretty big, so

possibly Show quoted text

> I missed them. Nevertheless, clearly 0.8123 passed on a lot of machines,

Show quoted text

> and where it failed, didn't necessarily say anything about Carp::Clan. > > Should such a test be included, if it is not already? >

Not really. DBIx::Class 0.08123 clearly indicates it requires Carp::Clan [1]. Having tests that verify that the necessary modules were indeed loaded is rather superfluous, because the impact of a broken toolchain is immediately apparent (as you saw). All in all whoever built the ppm screwed up royally, and it was not immediately apparent to you because ppm installs do not execute any tests. This is why it is always preferred to use the CPAN toolchain (cpan/cpanm/cpanp) as opposed to ppm. I will wait for you to confirm the above fully answers your question before closing this ticket. Cheers [1] https://metacpan.org/source/FREW/DBIx-Class-0.08123/META.yml#L34

Fri Feb 15 08:01:49 2013 ribasushi [...] leporine.io - Correspondence added

Subject:	Re: [rt.cpan.org #83340] Test that DBIC Modules Load
Date:	Sat, 16 Feb 2013 00:01:37 +1100
To:	Daniel Perrett via RT <bug-DBIx-Class [...] rt.cpan.org>
From:	Peter Rabbitson <ribasushi [...] cpan.org>

On Fri, Feb 15, 2013 at 07:29:02AM -0500, Daniel Perrett via RT wrote: Show quoted text

> Queue: DBIx-Class > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83340 > > > Thanks for the advice that best practice is to use cpan in the first > instance instead of ppm: I'll do that in future. > > "Having tests that verify that the necessary modules were indeed loaded is > rather superfluous" > I agree loading the dependencies is redundant. I meant something like > use_ok('DBIx::Class::Exception'), as distinct from duck-testing (if you > know what I mean) the functionality of the module.

Given that many critical parts of the distribution (e.g. DBIx::Class::Schema) use() DBIx::Class::Exception - a use_ok is just as redundant - 95% of your tests will fail anyway. One could argue that tests are cheap, and a use_ok wouldn't hurt, however as a counter-argument I shall present this: http://code.activestate.com/ppm/DBIx-Class/ The unavailability of latest DBIC on many of the platforms is because our test suite does not complete in under 5 minutes. Not because DBIC is horrifically slow, but because we have a lot of tests ;)

Fri Feb 15 08:07:23 2013 dperrett [...] cambridge.org - Correspondence added

Subject:	Re: [rt.cpan.org #83340] Test that DBIC Modules Load
Date:	Fri, 15 Feb 2013 13:06:59 +0000
To:	bug-DBIx-Class [...] rt.cpan.org
From:	Daniel Perrett <dperrett [...] cambridge.org>

Ah, ok - no problem, then. I was just really checking if use_ok()s were missed off unintentionally! Daniel From: "Peter Rabbitson via RT" <bug-DBIx-Class@rt.cpan.org> To: dperrett@cambridge.org Date: 15/02/2013 13:02 Subject: Re: [rt.cpan.org #83340] Test that DBIC Modules Load <URL: https://rt.cpan.org/Ticket/Display.html?id=83340 > On Fri, Feb 15, 2013 at 07:29:02AM -0500, Daniel Perrett via RT wrote: Show quoted text

> Queue: DBIx-Class > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83340 > > > Thanks for the advice that best practice is to use cpan in the first > instance instead of ppm: I'll do that in future. > > "Having tests that verify that the necessary modules were indeed loaded

is Show quoted text

> rather superfluous" > I agree loading the dependencies is redundant. I meant something like > use_ok('DBIx::Class::Exception'), as distinct from duck-testing (if you > know what I mean) the functionality of the module.

Given that many critical parts of the distribution (e.g. DBIx::Class::Schema) use() DBIx::Class::Exception - a use_ok is just as redundant - 95% of your tests will fail anyway. One could argue that tests are cheap, and a use_ok wouldn't hurt, however as a counter-argument I shall present this: http://code.activestate.com/ppm/DBIx-Class/ The unavailability of latest DBIC on many of the platforms is because our test suite does not complete in under 5 minutes. Not because DBIC is horrifically slow, but because we have a lot of tests ;)

Fri Feb 15 12:25:36 2013 ribasushi [...] leporine.io - Correspondence added

Rejecting ticket - side effect of a faulty (ancient) ppm.

Fri Feb 15 12:25:39 2013 ribasushi [...] leporine.io - Status changed from 'open' to 'rejected'