This queue is for tickets about the DBIx-Class CPAN distribution.

Report information
The Basics
Id:
83340
Status:
rejected
Priority:
Low/Low
Queue:

People
Owner:
Nobody in particular
Requestors:
dperrett [...] cambridge.org
Cc:
AdminCc:

BugTracker
Severity:
(no value)
Broken in:
(no value)
Fixed in:
(no value)

Attachments


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

Message body not shown because it is not plain text.

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
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:
> 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


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 ;)
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:
>        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 ;)


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


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.