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

Build.PL loses develop.* when generating MYMETA.json #34

Open
kentfredric opened this issue Oct 20, 2013 · 5 comments
Open

Build.PL loses develop.* when generating MYMETA.json #34

kentfredric opened this issue Oct 20, 2013 · 5 comments

Comments

@kentfredric
Copy link

When using Dist::Zilla, its pretty common for dists to ship with develop.requires in META.json.

It seems other metadata does get copied from META.json, just seems like prereqs is ignored in META.json and replaced, thus, the absence of develop.* in Build.PL means MYMETA.json has no develop_requires

This is not a serious dilemma , but annoying, as it means you can't simply do cpanm --with-develop --installdeps . on a build tree, because cpanm extracts deps from MYMETA.json.

Sure, cpanm could be adjusted to check META.json, but it seems more applicable to fix Module::Build here.

Especially seeing how small the difference is between META.json and the respective MYMETA.json is, namely, most differences are stringification, and the only notable differences are in repository. and prereqs.develop.

--- META.json   2013-10-21 00:27:08.208963123 +1300
+++ MYMETA.json 2013-10-21 00:39:12.919970919 +1300
@@ -4,7 +4,7 @@
       "Kent Fredric <[email protected]>"
    ],
    "dynamic_config" : 0,
-   "generated_by" : "Dist::Zilla version 4.300039, CPAN::Meta::Converter version 2.132830",
+   "generated_by" : "Module::Build version 0.4007, CPAN::Meta::Converter version 2.132830",
    "license" : [
       "perl_5"
    ],
@@ -24,21 +24,6 @@
             "Module::Build" : "0.4007"
          }
       },
-      "develop" : {
-         "requires" : {
-            "Dist::Zilla::PluginBundle::Author::KENTNL" : "2.000000",
-            "Pod::Coverage::TrustPod" : "0",
-            "Test::CPAN::Changes" : "0.19",
-            "Test::CPAN::Meta" : "0",
-            "Test::Kwalitee" : "1.12",
-            "Test::Pod" : "1.41",
-            "Test::Pod::Coverage" : "1.08",
-            "version" : "0.9901"
-         },
-         "suggests" : {
-            "Dist::Zilla::PluginBundle::Author::KENTNL::Lite" : "v1.3.0"
-         }
-      },
       "runtime" : {
          "requires" : {
             "Class::Tiny" : "0",
@@ -103,9 +88,7 @@
       },
       "homepage" : "https://github.com/kentfredric/Gentoo-Dependency-AST",
       "repository" : {
-         "type" : "git",
-         "url" : "https://github.com/kentfredric/Gentoo-Dependency-AST.git",
-         "web" : "https://github.com/kentfredric/Gentoo-Dependency-AST"
+         "url" : "https://github.com/kentfredric/Gentoo-Dependency-AST.git"
       }
    },
    "version" : "0.001000",
@@ -133,11 +116,11 @@
       },
       "perl" : {
          "original" : "v5.19.3",
-         "qv" : 1,
+         "qv" : "1",
          "version" : [
-            5,
-            19,
-            3
+            "5",
+            "19",
+            "3"
          ]
       },
       "perl-config" : {
@@ -524,4 +507,3 @@
    },
    "x_authority" : "cpan:KENTNL"
 }
-
@Leont
Copy link
Member

Leont commented Oct 20, 2013

This sounds like yet another consequence of #18. #31 probably fixes this issue.

@Leont
Copy link
Member

Leont commented Nov 18, 2013

Actually, #31 fixes this but breaks other stuff (#38). Bummer.

@Leont
Copy link
Member

Leont commented Nov 18, 2013

I suspect the long term solution is for dzil to pass this on to Module::Build's Build.PL, but we first need a hook to pass it on to.

@kentfredric
Copy link
Author

I figure as long as dynamic_config = 0, you could perhaps take the META.json verbatim like Module::Build::Tiny does.

@Leont
Copy link
Member

Leont commented Jan 17, 2014

I figure as long as dynamic_config = 0, you could perhaps take the META.json verbatim like Module::Build::Tiny does.

I suppose that could be a workable solution.

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

2 participants