Skip Menu |
 

This queue is for tickets about the Prophet CPAN distribution.

Report information
The Basics
Id: 88537
Status: open
Priority: 0/
Queue: Prophet

People
Owner: ioanr [...] cpan.org
Requestors: FLH [...] cpan.org
lxp [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.751
Fixed in: (no value)



Subject: tests fail even when all "recommended" dependencies are installed
Download (untitled) / with headers
text/plain 508b
Prophet is failing to install for me using cpanminus. The verbose output of cpanminus does not give anything obvious away. Many is() tests are simply failing with empty "got" values and quite a few failures are being reported from Config::GitLike: Can't use an undefined value as a HASH reference at .../Config/GitLike.pm line 429. Use of uninitialized value in concatenation (.) or string at .../Config/GitLike.pm line 124. My full cpanminus output is available here: https://gist.github.com/Lx/6494577
Subject: Newer Config::GitLike breaks sd
Download (untitled) / with headers
text/plain 475b
Dear authors, I've been playing with sd 0.75 (on Debian testing), which works fine with Config::GitLike version 1.08. Yet, Debian upgraded to Config::GitLike 1.10, and now almost all sd commands break with the following error: Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/Config/GitLike.pm line 135. Downgrading Config::GitLike to 1.08 solves the issue. Is there any way to fix sd with the more recent version of Config::GitLike? Thanks.
Download (untitled) / with headers
text/plain 124b
[rt.cpan.org #88538] suggests that the Config::GitLike errors are caused by an API change in Config::GitLike v1.09 or newer.
Some of the bugs in the gist were in the test suite, and are now fixed in git master.

So far, I'm unable to reproduce the Config::GitLike errors. I have 1.12 installed.


Download (untitled) / with headers
text/plain 472b
Le Mar 10 Sep 2013 04:50:26, IOANR a écrit : Show quoted text
> So far, I'm unable to reproduce the Config::GitLike errors. I have > 1.12 installed.
I've just installed Config::GitLike 1.12 from CPAN, and I still get the same error with sd 0.75: $ export SD_REPO=~/sd_test $ sd init Use of uninitialized value in concatenation (.) or string at /usr/local/share/perl/5.14.2/Config/GitLike.pm line 135. I'll try to investigate what causes this error on my computer in the next few days.
Download (untitled) / with headers
text/plain 933b
On Tue Sep 10 18:50:26 2013, IOANR wrote: Show quoted text
> So far, I'm unable to reproduce the Config::GitLike errors. I have > 1.12 installed.
In case this helps, one of the warnings I mentioned earlier: Show quoted text
> Can't use an undefined value as a HASH reference at > .../Config/GitLike.pm line 429.
references this line of Config::GitLike v1.12: if ( !defined $self->origins->{$key} || ... ) { suggesting that $self->origins is undefined at the time of the call. However, the definition for the "origins" attribute is meant to prohibit instantiation with an undefined "origins" value: use Moo; use MooX::Types::MooseLike::Base qw( ... HashRef ... ); ... has 'origins' => ( is => 'rw', isa => HashRef, default => sub { +{} }, ); suggesting that Moo itself could be the problem. I had Moo v1.003 installed when I experienced these warnings, but upgrading to Moo v1.003001 has not fixed the problem.
Download (untitled) / with headers
text/plain 668b
On Tue Sep 10 19:10:08 2013, FLH wrote: Show quoted text
> Use of uninitialized value in concatenation (.) or string at > /usr/local/share/perl/5.14.2/Config/GitLike.pm line 135.
This warning and another one referencing line 124 indicate that the "confname" attribute of the GitLike object is undefined. As per the "origins" attribute (see my previous message), this is in breach of the attribute's definition: has 'confname' => ( is => 'rw', required => 1, isa => Str, ); This continues to suggest a Moo problem. Another possibility is that something is directly modifying/clearing the underlying hash used by Moo for holding the object's state.
Download (untitled) / with headers
text/plain 571b
On Thu Sep 12 23:52:14 2013, LXP wrote: Show quoted text
> This continues to suggest a Moo problem. > > Another possibility is that something is directly modifying/clearing > the underlying hash used by Moo for holding the object's state.
I also note that Prophet::Config (which "extends" Config::GitLike) uses Any::Moose while Config::GitLike itself uses Moo. I wonder if it's possible that Any::Moose is somehow interfering. All of these modules on my system are at their latest versions: $ pmvers Any::Moose Moo Config::GitLike Any::Moose: 0.21 Moo: 1.003001 Config::GitLike: 1.12
Download (untitled) / with headers
text/plain 360b
On Fri Sep 13 00:04:04 2013, LXP wrote: Show quoted text
> I wonder if it's possible that Any::Moose is somehow interfering.
Apparently Any::Moose is now deprecated in favour of Moo. While a quick glance at the Any::Moose code suggests that it shouldn't be interfering with Moo, I wonder whether simply replacing all of the "Any::Moose" references with "Moo" will fix things.
Thanks for all you've done so far. I'll see if I can reproduce the failures sometime in the next few days.

Unfortunately, replacing Any::Moose with Moo alone would break things more because of the use of Moose types, and differences in how Moo handles type coercion.

I'm in the middle of a refactor (AnyMoose_to_Moo branch on gitorious), though I'm only getting a day or two a month to work on it.



I've finally got the time to look at this again. 

The problem is caused somehow by Mouse, which I must not have had installed during my previous attempts to reproduce.

As a workaround, setting ANY_MOOSE=Moose gets the test suite passing.



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.