Skip Menu |
 

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

Report information
The Basics
Id: 83340
Status: rejected
Priority: 0/
Queue: DBIx-Class

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

Bug Information
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>
Download (untitled) / with headers
text/plain 1.7k
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>
Download (untitled) / with headers
text/plain 1.7k
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>
Download (untitled) / with headers
text/plain 2.4k
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
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>
Download (untitled) / with headers
text/plain 1.1k
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>
Download (untitled) / with headers
text/plain 1.4k
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 ;)
Rejecting ticket - side effect of a faulty (ancient) ppm.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

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