Bug #87123 for Dist-Zilla-Plugin-Conflicts: conflict entries in 'prereq' field are not added

Sun Jul 21 12:35:00 2013 ether [...] cpan.org - Ticket created

Subject:

conflict entries in 'prereq' field are not added

https://metacpan.org/module/CPAN::Meta::Spec#Prereq-Spec describes a 'conflicts' relationship for prereqs. It would make sense for an entry to be added here with the information passed to this plugin. I would suggest adding to both the runtime and develop phases. Here's the code needed: sub register_prereqs { my $self = shift; ... original code here... $self->zilla->register_prereqs( { type => 'conflicts', phase => $_, }, %{ $self->_conflicts }, ) foreach (qw(develop runtime)); }

Fri Jul 26 14:13:29 2013 ether [...] cpan.org - Correspondence added

On 2013-07-21 09:35:00, ETHER wrote: Show quoted text

> Here's the code needed: > > sub register_prereqs > { > my $self = shift; > > ... original code here... > > $self->zilla->register_prereqs( > { > type => 'conflicts', > phase => $_, > }, > %{ $self->_conflicts }, > ) foreach (qw(develop runtime)); > }

Actually.. it might be better to add the entries with '<=' -- the metaspec says: "These libraries cannot be installed when the phase is in operation. This is a very rare situation, and the conflicts relationship should be used with great caution, or not at all." So if we just put in the *last* known-bad version into metadata, that won't encompass all the previous versions as well (that are presumably also bad). my %conflicts = keys %{ $self->_conflicts }; $self->zilla->register_prereqs( { type => 'conflicts', phase => $_, }, ( map { $_ => '<= ' . $conflicts{$_} } keys %conflicts ), ) foreach (qw(develop runtime));

Fri Jul 26 16:11:08 2013 ether [...] cpan.org - Correspondence added

On 2013-07-26 11:13:29, ETHER wrote: Show quoted text

> Actually.. it might be better to add the entries with '<=' -- the > metaspec says:

Screw "it might be better" - it *needs* to be done that way. The current entries are being inflated into ranges by CPAN::Meta::Prereqs and are coming out backwards -- see the second issue I describe at https://github.com/Leont/cpan-meta-check/pull/4. Patched in https://github.com/karenetheridge/Dist-Zilla-Plugin-Conflicts/tree/topic/fix_conflicts_ranges So sorry! I should have tested better. But yay Moose releases for making the failure blatantly obvious ;)

Sun Jul 28 12:40:26 2013 ether [...] cpan.org - Correspondence added

On 2013-07-26 13:11:08, ETHER wrote: Show quoted text

> On 2013-07-26 11:13:29, ETHER wrote: >

> > Actually.. it might be better to add the entries with '<=' -- the > > metaspec says:

> > Screw "it might be better" - it *needs* to be done that way. The > current > entries are being inflated into ranges by CPAN::Meta::Prereqs and are > coming > out backwards -- see the second issue I describe at > https://github.com/Leont/cpan-meta-check/pull/4. > > Patched in https://github.com/karenetheridge/Dist-Zilla-Plugin- > Conflicts/tree/topic/fix_conflicts_ranges > > So sorry! I should have tested better. But yay Moose releases for > making the > failure blatantly obvious ;)

BTW - those RuntimeConflict entries in dist.ini could also be expressed as [Conflicts] entries, but if you add that, please release your dist with version 0.10 of itself, not 0.11, so the metadata doesn't come out wrong :D Also, if you don't get around to releasing this right away, I think it would be valuable to delete 0.11 from PAUSE, so we don't have bad metadata getting out there. I'm going to do a cpan-grep for what dists use [Conflicts] currently, but its copy of PAUSE hasn't been updated in a few months, so that won't give totally accurate information.

Fri Aug 02 16:02:19 2013 ether [...] cpan.org - Correspondence added

Gah I just realized another mistake I made regarding this issue... will push more commits to the branch.

Fri Aug 02 16:25:25 2013 ether [...] cpan.org - Correspondence added

On 2013-08-02 13:02:19, ETHER wrote: Show quoted text

> Gah I just realized another mistake I made regarding this issue... > will push more commits to the branch.

Right, so I forgot that there is no pull request here, so all the commentary needs to be in this ticket... What we have here is an unfortunate conflict (ha ha!) between the meaning you (and Dist::CheckConflicts) were using for 'conflict', and what the metaspec decided conflicts meant. They're actually two TOTALLY separate things. In the metaspec, a conflict entry means "this specified version [range] CANNOT BE INSTALLED while this phase is running". Dist::CheckConflicts's version is "this thing is now broken, but since the dependency is reversed, you're going to have to update it afterwards, rather than us doing that for you now." So saying that installing this version of Foo now breaks Bar 1.0 and earlier is totally different from "we're going to fall over and die if Bar 1.0 is installed". The new commits force-pushed to this branch address that, by totally removing my braindead attempts to add metadata -- and I added proper dist.ini entries for the *right* kind of conflicts that are present in each case (specifically: do not release the dist with [Conflicts] version 0.11, so 0.12 doesn't get bad metadata in it, and now that 0.11 is removed from PAUSE, the other "breaks" entries (on Test::CheckDeps <= 0.006, [CheckPrereqsIndexed <= 0.009, [ReportVersions::Tiny] <= 1.08) are now irrelevant, as we're once again not adding conflict metadata. I'd actually suggest renaming this module (and Dist::CheckConflicts) to *Breaks, to further disambiguate the meanings. I'll pursue that with doy, and poke you again when that happens. I'm so sorry again. It's fortunate that you didn't have the tuits to release 0.12 last weekend, as it would have still been broken :)

Sat Apr 05 17:00:26 2014 ether [...] cpan.org - Correspondence added

This is all tidied up now in [Breaks], and the changes in https://github.com/karenetheridge/Dist-Zilla-Plugin-Conflicts/pull/1 fix the metadata to use '<= '.

Sat Apr 05 17:00:27 2014 ether [...] cpan.org - Status changed from 'new' to 'rejected'