Skip Menu |

This queue is for tickets about the Dist-Zilla-Plugin-Conflicts CPAN distribution.

Report information
The Basics
Id: 76496
Status: resolved
Priority: 0/
Queue: Dist-Zilla-Plugin-Conflicts

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

Bug Information
Severity: Normal
Broken in: 0.08
Fixed in: 0.15



Subject: [Conflicts] does not cooperate with [Test::Version] and [PkgVersion]
The Conflicts plugin generates a .pm file that doesn't get a $VERSION via [PkgVersion] - which makes [Test::Version] fail. This is because Conflicts hooks into register_prereqs, and PkgVersion is a FileMunger, which runs just before register_prereqs. I don't have an idea for solving this, yet, so I'm throwing this out there hoping someone will.
On Wed Apr 11 10:42:52 2012, ETHER wrote: Show quoted text
> The Conflicts plugin generates a .pm file that doesn't get a $VERSION > via [PkgVersion] - which makes [Test::Version] fail. > > This is because Conflicts hooks into register_prereqs, and PkgVersion is > a FileMunger, which runs just before register_prereqs. > > I don't have an idea for solving this, yet, so I'm throwing this out > there hoping someone will.
Thoughts: - [PkgVersion] modifies the file to insert the $VERSION with $plugin->munge_file($file) - in [Conflicts] _build_conflicts_file, before returning the File::InMemory object, we need to check if [PkgVersion] is being used as a plugin (or perhaps other similar plugins that do similar things) - if so, call munge_file to modify the contents. This is ugly - I don't know if there is historical precedence for one plugin having to be aware of another plugin's existence. (This vaguely feels like one role checking to see if another role is involved in class composition - smelly!) Could this be made cleaner somehow? Perhaps with a new role that whose existence can be tested for, like Dist::Zilla::Role::VersionInserter?
irc dump: 11:22 < ether> rjbs: anyway yeah I agree what I sketched out on that ticket is horrid, but I can't think of a better way. so pondering is good :) 11:22 < rjbs> kentnl proposed, some time ago, that mungers would push a munging callback onto files, to be applied as required later 11:23 < Show quoted text
ether> that sounds nice
11:23 < rjbs> I'm not a huge fan, but it's a potential solution for this case. 11:23 < ether> right, so [PkgVersion] would register a callback munger for .pm and executable files, and something in Role::File would go "oh hey someone created a new one of these, I'll apply the filter now" 11:24 < rjbs> PkgVersion would find all the files it cared about and do something like $file->push_munger($coderef) 11:24 < ether> well it can't do it on specific files, because the file in question here hasn't been created yet 11:24 < rjbs> the Conflicts thing can (and should) add its file at file-gathering time, as a FromCode file 11:25 < ether> oh, I didn't realize that was possible 11:25 < rjbs> files that are not added during file-gathering is a red flag 11:25 < ether> I was about to say "looking at it another way, the problem is that the Conflicts plugin generates its file too late" 11:25 < rjbs> yes 11:25 < ether> so it can signal its intention to create a file, and provide a coderef for generating it, but that coderef isn't run until later (when the prereqs are known, to fill in the file contents)?
I can make the files be FromCode files and add them in the FileGatherer phase, but they still cannot be munged by PkgVersion (or anything) because they are FromCode files. I'm not sure if that's any better than before.
Subject: 0001-Generate-FromCode-files-during-FileGatherer-phase.patch
From 64199bea318d4add5e4eff1e2cdbdad31bc481e2 Mon Sep 17 00:00:00 2001 From: Mike Doherty <doherty@cs.dal.ca> Date: Sat, 14 Jul 2012 01:09:03 -0300 Subject: [PATCH] Generate FromCode files during FileGatherer phase Previously, this plugin didn't play nicely with PkgVersion, for example, because the files were injected too late. Now, we create FromCode files and inject them early (in the FileGatherer phase). Resolves RT #76496: [Conflicts] does not cooperate with [Test::Version] and [PkgVersion] --- Changes | 3 + lib/Dist/Zilla/Plugin/Conflicts.pm | 128 +++++++++++++++++------------------- 2 files changed, 63 insertions(+), 68 deletions(-) diff --git a/Changes b/Changes index 5f44490..010e307 100644 --- a/Changes +++ b/Changes @@ -1,5 +1,8 @@ {{$NEXT}} +- RT #76496: Build the injected files as FromCode files during the + FileGatherer phase (Mike Doherty) + 0.08 2011-07-22 - Add Dist::CheckConflicts to both configures and runtime dependency lists for diff --git a/lib/Dist/Zilla/Plugin/Conflicts.pm b/lib/Dist/Zilla/Plugin/Conflicts.pm index bb241b5..07c0c24 100644 --- a/lib/Dist/Zilla/Plugin/Conflicts.pm +++ b/lib/Dist/Zilla/Plugin/Conflicts.pm @@ -5,7 +5,7 @@ use warnings; use Dist::CheckConflicts 0.01 (); use Moose::Autobox 0.09; - +use Dist::Zilla::File::FromCode; use Moose; with qw( @@ -13,6 +13,7 @@ with qw( Dist::Zilla::Role::MetaProvider Dist::Zilla::Role::PrereqSource Dist::Zilla::Role::TextTemplate + Dist::Zilla::Role::FileGatherer ); has _conflicts => ( @@ -89,20 +90,6 @@ sub register_prereqs { ); } -# This should be done in the file gatherer stage, but that happens _before_ -# prereqs are registered, and we can't generate our conflict module until -# after we know all the prereqs. -after register_prereqs => sub { - my $self = shift; - - $self->add_file( $self->_build_conflicts_file() ); - - $self->add_file( $self->_build_script() ) - if $self->_has_script(); - - return; -}; - my $conflicts_module_template = <<'EOF'; package # hide from PAUSE {{ $module_name }}; @@ -121,42 +108,7 @@ use Dist::CheckConflicts 1; EOF -sub _build_conflicts_file { - my $self = shift; - - my $conflicts = $self->_conflicts(); - - my $conflicts_dump = join ",\n ", - map {qq['$_' => '$conflicts->{$_}']} sort keys %{$conflicts}; - - my $also_dump = join "\n ", - sort grep { $_ ne 'perl' } - map { $_->required_modules() } - $self->zilla()->prereqs()->requirements_for(qw(runtime requires)); - - $also_dump - = ' -also => [ qw(' . "\n" - . ' ' - . $also_dump . "\n" - . ' ) ],' . "\n" - if length $also_dump; - - ( my $dist_name = $self->zilla()->name() ) =~ s/-/::/g; - - my $content = $self->fill_in_string( - $conflicts_module_template, { - dist_name => \$dist_name, - module_name => \( $self->_conflicts_module_name() ), - conflicts_dump => \$conflicts_dump, - also_dump => \$also_dump, - }, - ); - return Dist::Zilla::File::InMemory->new( - name => $self->_conflicts_module_path(), - content => $content, - ); -} # If dzil sees this string PODXXXX anywhere in this code it uses that as the # name for the module. @@ -185,23 +137,6 @@ else { EOF $script_template = sprintf( $script_template, $podname_hack ); -sub _build_script { - my $self = shift; - - ( my $filename = $self->_script() ) =~ s+^.*/++; - my $content = $self->fill_in_string( - $script_template, { - filename => \$filename, - module_name => \( $self->_conflicts_module_name() ), - }, - ); - - return Dist::Zilla::File::InMemory->new( - name => $self->_script(), - content => $content, - ); -} - # XXX - this should really be a separate phase that runs after InstallTool sub setup_installer { my $self = shift; @@ -216,7 +151,64 @@ sub setup_installer { } return; -}; +} + +sub gather_files { + my $self = shift; + my $zilla = $self->zilla; + + my $module = Dist::Zilla::File::FromCode->new({ + name => $self->_conflicts_module_path, + code => sub { + my $conflicts = $self->_conflicts(); + + my $conflicts_dump = join ",\n ", + map {qq['$_' => '$conflicts->{$_}']} sort keys %{$conflicts}; + + my $also_dump = join "\n ", + sort grep { $_ ne 'perl' } + map { $_->required_modules() } + $self->zilla()->prereqs()->requirements_for(qw(runtime requires)); + + $also_dump + = ' -also => [ qw(' . "\n" + . ' ' + . $also_dump . "\n" + . ' ) ],' . "\n" + if length $also_dump; + + ( my $dist_name = $self->zilla()->name() ) =~ s/-/::/g; + + return $self->fill_in_string( + $conflicts_module_template, { + dist_name => \$dist_name, + module_name => \( $self->_conflicts_module_name() ), + conflicts_dump => \$conflicts_dump, + also_dump => \$also_dump, + }, + ); + }, # end sub + }); + $self->add_file($module); + warn "added module: $module at @{[ $self->_conflicts_module_path ]}"; + + if ($self->_has_script) { + my $script = Dist::Zilla::File::FromCode->new({ + name => $self->_script(), + code => sub { + ( my $filename = $self->_script() ) =~ s+^.*/++; + return $self->fill_in_string( + $script_template, { + filename => \$filename, + module_name => \( $self->_conflicts_module_name() ), + }, + ); + }, # end sub + }); + $self->add_file($script); + warn "added script: $script"; + } +} sub _munge_makefile_pl { my $self = shift; -- 1.7.9.5
I changed the plugin to be a FileGatherer, but the PkgVersion plugin ends up skipping the generated module because it's package line looks like this: package # hide from PAUSE Foo::Bar::Conflicts; I changed PkgVersion to skip things like this a long time ago because it ends up giving $VERSIONs to all sorts of junk like packages in test files otherwise, and it generally makes a mess. So I guess I could _not_ hide the Conflicts module from PAUSE. I think I should generate some POD for the module too if I un-hide it.
On 2013-04-01 12:44:40, DROLSKY wrote: Show quoted text
> I changed the plugin to be a FileGatherer, but the PkgVersion plugin > ends up skipping the generated module because it's package line looks > like this: > > package # hide from PAUSE > Foo::Bar::Conflicts; > > I changed PkgVersion to skip things like this a long time ago because > it ends up giving $VERSIONs to all sorts of junk like packages in test > files otherwise, and it generally makes a mess. > > So I guess I could _not_ hide the Conflicts module from PAUSE. I think > I should generate some POD for the module too if I un-hide it.
The changes you made resolve the core issue - that [Test::Version] is unhappy with the generated package -- so I'm content to close this. thanks!
Show quoted text
> The changes you made resolve the core issue - that [Test::Version] is > unhappy with the generated package -- so I'm content to close this. > thanks!
...or rather, the main issue of what phase(s) the file was created in. https://github.com/xenoterracide/Test-Version/issues/4 remains open, but that's not your problem. :)
On 2013-04-01 12:44:40, DROLSKY wrote: Show quoted text
> I changed the plugin to be a FileGatherer...
This is not as good a solution as Mike Doherty's patch to use a FromCode file, because now the file contents are being calculated before the distribution has determined the prerequisite list. Consequently, there will be no '-also' clause added to the Dist::CheckConflicts call. This affects Moose, which used to check for Package::Stash conflicts and no longer does. https://metacpan.org/diff/file?target=ETHER/Moose-2.0802/&source=ETHER/Moose-2.0801/#lib/Moose/Conflicts.pm
On Thu Aug 28 20:12:48 2014, ETHER wrote: Show quoted text
> On 2013-04-01 12:44:40, DROLSKY wrote:
> > I changed the plugin to be a FileGatherer...
> > This is not as good a solution as Mike Doherty's patch to use a > FromCode file, because now the file contents are being calculated > before the distribution has determined the prerequisite list. > Consequently, there will be no '-also' clause added to the > Dist::CheckConflicts call. This affects Moose, which used to check > for Package::Stash conflicts and no longer does. > > https://metacpan.org/diff/file?target=ETHER/Moose- > 2.0802/&source=ETHER/Moose-2.0801/#lib/Moose/Conflicts.pm
Karen, can you think of how to come up with a test for this? That'd make fixing this easier, obviously. Actually having tests for this module would probably be a plus in general ;)
Subject: Re: [rt.cpan.org #76496] [Conflicts] does not cooperate with [Test::Version] and [PkgVersion]
Date: Sat, 30 Aug 2014 14:44:10 -0700
To: Dave Rolsky via RT <bug-Dist-Zilla-Plugin-Conflicts [...] rt.cpan.org>
From: Karen Etheridge <ether [...] cpan.org>
On Sat, Aug 30, 2014 at 04:33:07PM -0400, Dave Rolsky via RT wrote: Show quoted text
> Karen, can you think of how to come up with a test for this? That'd make fixing this easier, obviously. Actually having tests for this module would probably be a plus in general ;)
Sure, I can send you a PR containing the patch and some tests. I've written enough dzil plugin tests now that it's a breeze :)