-
Notifications
You must be signed in to change notification settings - Fork 2
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
Comments
Here's another solution... kind of gross, and I need to sleep on it to be sure how wretched it is:
* this also has the advantage that you can be sure that the |
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. |
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. |
Dist::Zilla::Plugin::MetaProvides::Update is now shipped as part of Dist-Zilla-PluginBundle-Git-VersionManager. |
as per irc:
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 incorrectprovides
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
.The text was updated successfully, but these errors were encountered: