Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

warn when $VERSIONs are extracted from files too soon #8

Open
karenetheridge opened this issue Jul 2, 2017 · 4 comments
Open

warn when $VERSIONs are extracted from files too soon #8

karenetheridge opened this issue Jul 2, 2017 · 4 comments

Comments

@karenetheridge
Copy link

as per irc:

16:11 <%ether> kentnl: you really should have [MetaProvides::*] warn when it runs before [PkgVersion], [OurPkgVersion] or [RewriteVersion], because it will be creating bogus metadata

In my case, the problem is between the plugins [MetaProvides::Package], [PodWeaver] and [RewriteVersion] -- PodWeaver calls $zilla->distmeta which calls into MetaProvides::*, but the correct $VERSION hasn't been munged into the .pm file by [RewriteVersion] yet, so incorrect provides metadata results.

Perhaps an after_build sub could re-scan for package versions and warn (or die?) when they are different from what was put into provides.

@karenetheridge
Copy link
Author

karenetheridge commented Jul 3, 2017

Here's another solution... kind of gross, and I need to sleep on it to be sure how wretched it is:

  • compose ::Role::PrereqSource in your plugins

  • if the PrereqSource phase hasn't run yet, simply return this in the metadata sub:

# deliberately violates CPAN::Meta::Spec, so we can be sure we eventually replace this value
{ provides => 'placeholder, to be filled in later by ' . blessed($self) };

  • in the register_prereqs sub, populate $zilla->distmeta->{provides} with the real data. (This phase is late enough that we can be sure all file munging is complete, but early enough that files haven't started to be written out to disk yet.)

* this also has the advantage that you can be sure that the no_index key has already been populated in distmeta, so you don't have to jump through hoops looking for that plugin to call it explicitly.

@karenetheridge
Copy link
Author

I've implemented this in Dist::Zilla::Plugin::MetaProvides::Update in my author bundle (to be soon split out into Dist::Zilla::PluginBundle::Git::VersionManager) to correct for problematic plugin ordering. I would be in support of the code being stolen (with coordination :)) to live directly in Dist::Zilla::Role::MetaProvides::Provider in the PrereqSource phase.

@karenetheridge
Copy link
Author

I just filed https://rt.cpan.org/Ticket/Display.html?id=122576, which would let us see how many distributions are publishing incorrect provides metadata today.

@karenetheridge
Copy link
Author

Dist::Zilla::Plugin::MetaProvides::Update is now shipped as part of Dist-Zilla-PluginBundle-Git-VersionManager.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant