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
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
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.
[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.


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