Skip Menu |

This queue is for tickets about the GnuPG-Interface CPAN distribution.

Report information
The Basics
Id: 93826
Status: resolved
Priority: 0/
Queue: GnuPG-Interface

People
Owner: Nobody in particular
Requestors: MCARDWELL [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: 0.48
Fixed in: (no value)



Subject: Breaking behaviour in $key->user_ids when upgrading from 0.46 to 0.48
I was running GnuPG::Interface 0.46 and the following code worked fine: my $gnupg = GnuPG::Interface->new; foreach my $key ($gnupg->get_public_keys( $email )){ foreach my $uid ($key->user_ids){ # Do stuff with UID } } Then I just did an "apt-get dist-upgrade" on my Debian Testing machine, and one of the packages it updated was GnuPG::Interface, to version 0.48. Now the above code is broken. It seems that "$uid" in the above code, is no longer a GnuPG::PublicKey, but is now an arrayref of GnuPG::PublicKey's. One of the other packages this breaks is Mail::GnuPG. I had to patch my local version of Mail::GnuPG to deal with this. I've also submitted a bug report to that package: https://rt.cpan.org/Ticket/Display.html?id=93797 You may have made this change on purpose, but it's not backwards compatible, breaks existing software, and I don't see it documented anywhere. Please restore the old behavior.
Subject: Re: [rt.cpan.org #93826] Breaking behaviour in $key->user_ids when upgrading from 0.46 to 0.48
Date: Thu, 13 Mar 2014 13:16:47 -0400
To: bug-GnuPG-Interface [...] rt.cpan.org
From: Alex Vandiver <alex [...] chmrr.net>
On Thu, 2014-03-13 at 05:25 -0400, Mike Cardwell via RT wrote: Show quoted text
> You may have made this change on purpose, but it's not backwards > compatible, breaks existing software, and I don't see it documented > anywhere. Please restore the old behavior.
Nope, it wasn't on purpose, hence why it wasn't documented. It was an accidental side-effect of a patch I accepted to transition from Any::Moose to Moo. I've just released 0.49 which restores backwards compatibility with 0.46 and below. - Alex
On Thu Mar 13 13:17:02 2014, alex@chmrr.net wrote: Show quoted text
> Nope, it wasn't on purpose, hence why it wasn't documented. It was an > accidental side-effect of a patch I accepted to transition from > Any::Moose to Moo. I've just released 0.49 which restores backwards > compatibility with 0.46 and below.
I'm sorry for having broken auto-dereferencing, and hence backwards compatibility, with my "migrate to Moo" patch. Unfortunately, the fix in 0.49 reintroduces the dependency on Moose, by using the metaclass. Note that this "new" dependency is not specified in the META files. I'm working on a slightly different (and quite less elegant) patch that fixes backwards compatibility, without reintroducing the dependency on Moose.
On Fri Mar 14 06:10:24 2014, intrigeri@boum.org wrote: Show quoted text
> I'm working on a slightly different (and quite less elegant) patch > that fixes backwards compatibility, without reintroducing the > dependency on Moose.
Patch attached. I'm happy to say that it does not look less elegant than the fix that went in 0.49, eventually.
Subject: 0001-Drop-reintroduced-dependency-on-Moose-by-using-the-M.patch
From ac8a34188fe883ebd1ce5dd4485ca00567bce124 Mon Sep 17 00:00:00 2001 From: intrigeri <intrigeri@boum.org> Date: Fri, 14 Mar 2014 10:46:29 +0000 Subject: [PATCH] Drop reintroduced dependency on Moose, by using the MooX::HandlesVia's "elements" instead of creating accessors with the metaclass. This is a follow-up on https://rt.cpan.org/Ticket/Display.html?id=93826: the way 0.49 restored backwards compatibility reintroduced the dependency on Moose, that we had previously get rid on in 0.47. --- lib/GnuPG/Options.pm | 6 +----- lib/GnuPG/PrimaryKey.pm | 12 ++++-------- t/get_public_keys.t | 4 ++-- 3 files changed, 7 insertions(+), 15 deletions(-) diff --git a/lib/GnuPG/Options.pm b/lib/GnuPG/Options.pm index a7c4203..65aba79 100644 --- a/lib/GnuPG/Options.pm +++ b/lib/GnuPG/Options.pm @@ -81,13 +81,9 @@ for my $list (LISTS) { default => sub { [] }, handles => { "push_$list" => 'push', + "$list" => 'elements', }, ); - - __PACKAGE__->meta->add_method($list => sub { - my $self = shift; - return wantarray ? @{$self->$ref(@_)} : $self->$ref(@_); - }); } sub BUILD { diff --git a/lib/GnuPG/PrimaryKey.pm b/lib/GnuPG/PrimaryKey.pm index bc84349..fc2a07a 100644 --- a/lib/GnuPG/PrimaryKey.pm +++ b/lib/GnuPG/PrimaryKey.pm @@ -28,13 +28,9 @@ for my $list (qw(user_ids subkeys user_attributes)) { default => sub { [] }, handles => { "push_$list" => 'push', + "$list" => 'elements', }, ); - - __PACKAGE__->meta->add_method($list => sub { - my $self = shift; - return wantarray ? @{$self->$ref(@_)} : $self->$ref(@_); - }); } has $_ => ( @@ -65,10 +61,10 @@ sub compare { ); foreach my $list (@lists) { - return 0 unless @{$self->$list} == @{$other->$list}; - for ( my $i = 0; $i < scalar(@{$self->$list}); $i++ ) { + return 0 unless $self->$list == $other->$list; + for ( my $i = 0; $i < scalar($self->$list); $i++ ) { return 0 - unless $self->$list->[$i]->compare($other->$list->[$i], 1); + unless ($self->$list)[$i]->compare(($other->$list)[$i], 1); } } } diff --git a/t/get_public_keys.t b/t/get_public_keys.t index 38661b7..c807f83 100644 --- a/t/get_public_keys.t +++ b/t/get_public_keys.t @@ -202,8 +202,8 @@ TEST TEST { - my $subkey1 = $given_key->subkeys()->[0]; - my $subkey2 = $handmade_key->subkeys()->[0]; + my $subkey1 = ($given_key->subkeys())[0]; + my $subkey2 = ($handmade_key->subkeys())[0]; bless $subkey1, 'GnuPG::SubKey'; -- 1.9.0
Subject: Re: [rt.cpan.org #93826] Breaking behaviour in $key->user_ids when upgrading from 0.46 to 0.48
Date: Fri, 14 Mar 2014 10:24:45 -0400
To: bug-GnuPG-Interface [...] rt.cpan.org
From: Alex Vandiver <alex [...] chmrr.net>
On Fri, 2014-03-14 at 06:10 -0400, intrigeri via RT wrote: Show quoted text
> I'm sorry for having broken auto-dereferencing, and hence backwards > compatibility, with my "migrate to Moo" patch.
No worries. Fair's fair, as I just apparently broke things with my "fix." :) Show quoted text
> Unfortunately, the fix in 0.49 reintroduces the dependency on Moose, by > using the metaclass. Note that this "new" dependency is not specified > in the META files.
Ahhh -- I wasn't aware that Moo didn't present any kind of metaclass, and that calling it made it step up to Moose. Whoops. Show quoted text
> I'm working on a slightly different (and quite less elegant) patch that > fixes backwards compatibility, without reintroducing the dependency on > Moose.
Yeah, using "elements" was also the first track I took earlier, as well. Unfortunately, it doesn't preserve the behavior of returning a ref in scalar context. :/ If using ->meta->add_method is out, we can use the old ugly kludge: no strict 'refs'; *{$list} = sub { my $list = shift; return wantarray ? @{$self->$ref(@_)} : $self->$ref(@_); }; - Alex
On Fri Mar 14 10:25:01 2014, alex@chmrr.net wrote: Show quoted text
> Yeah, using "elements" was also the first track I took earlier, as well. > Unfortunately, it doesn't preserve the behavior of returning a ref in > scalar context. :/
Ah, right. Show quoted text
> If using ->meta->add_method is out, we can use the old ugly kludge: > > no strict 'refs'; > *{$list} = sub { > my $list = shift; > return wantarray ? @{$self->$ref(@_)} : $self->$ref(@_); > };
Indeed. Do you plan to implement it soonish, or should I?
Subject: Re: [rt.cpan.org #93826] Breaking behaviour in $key->user_ids when upgrading from 0.46 to 0.48
Date: Fri, 14 Mar 2014 12:00:53 -0400
To: bug-GnuPG-Interface [...] rt.cpan.org
From: Alex Vandiver <alex [...] chmrr.net>
On Fri, 2014-03-14 at 11:50 -0400, intrigeri via RT wrote: Show quoted text
> > If using ->meta->add_method is out, we can use the old ugly kludge: > > > > no strict 'refs'; > > *{$list} = sub { > > my $list = shift; > > return wantarray ? @{$self->$ref(@_)} : $self->$ref(@_); > > };
> > Indeed. Do you plan to implement it soonish, or should I?
I'll push and release shortly. I just wanted to get a sanity check before doing so. - Alex