How to specify prerequisites for the "develop" phase?

[cubranic]

I understood with issue #31 M::B supports Meta 2.0, but I can't seem to specify requires for the "develop" phase. Adding "develop_requires" to Build.PL doesn't help as anything within it does not appear in META.json or META.yml. Is there a different way to do this or is it just not supported yet?

[Leont]

This is a duplicate of #34.

[cubranic]

I read #34 before opening this issue, and I just don't see my question answered there:

1. it talks about dzilla, which I don't use.
2. later on, you say that a workaround might be setting "dynamic_config" and/or taking "the META.json verbatim". I don't know what META.json is, or know how it's used. All of my prerequisites for other phases are in Build.PL and that's served me fine so far.
3. you mention there that Converted Module::Build to use Meta 2.0 inside #31 fixed the Build.PL loses develop.* when generating MYMETA.json #34's problem, and that the fix was released in 0.40_09. You also mention there that Module::Build 0.42 Broke optional dependency handling. #38 is related, but that one was supposedly fixed in 0.4202. I have 0.4205, and still have the same problem.

So, if I'm just using plain old Build.PL, is there a way to have a "requires" stanza for the "develop" phase? If so, how? If not, is there an alternative or workaround?

[Leont]

So, if I'm just using plain old Build.PL, is there a way to have a "requires" stanza for the "develop" phase? If so, how?

No, I don't think so.

If not, is there an alternative or workaround?

That should be meta_merge, however that doesn't currently work for prereqs. That is depending on Perl-Toolchain-Gang/CPAN-Meta#40.

[cubranic]

Thanks. Should I close this issue as WONTFIX then?

[Leont]

Thanks. Should I close this issue as WONTFIX then?

No, it's just stalled. This will be fixed at some point, but yaks have to be shaved first.

[Leont]

As of 0.4209, this would work for the META.json:

meta_merge     => {
  'meta-spec' => {
    version => 2
  },
  prereqs => {
      develop => {
          requires => {
              Foo => 1,
          },
     },
  },
},

It doesn't show up in the MYMETA though, I suspect that's what you want.

[theory]

It doesn't show up in the MYMETA though, I suspect that's what you want.

I just discovered that this merge data doesn't show up in MYMETA.json. I'm curious why not. I thought to use it with cpanm --installdeps --with-develop, but since the develop dependencies are not merged into MYMETA.json it doesn't install them. Just tried with Module::Build 0.4234.

[Leont]

I just discovered that this merge data doesn't show up in MYMETA.json. I'm curious why not.

1. merge_meta and merge_add are applied to the META file
2. When generating MYMETA, the existing prereqs entry is completely replaced by the values known to Module::Build at that time.

Could that be changed? Maybe; CPAN::Meta::Merge didn't exist yet when that part of the code was written. Could it break things? I could, especially with regards to dynamic dependencies. How likely is that? I don't really know.

[theory]

I would guess no more likely than it breaking things when merging into the META.json file. I've worked around it in my CI config, but I have to admit this seems surprising to me. On the other hand, since no one else has chimed in on this issue in the last 10 years, maybe it's not worth bothering with.

[Grinnz]

Does EUMM attempt to merge into MYMETA?

[Leont]

Does EUMM attempt to merge into MYMETA?

No it has the same behavior.

Apparently, I did try to implement this 11.5 years ago in 66aa1e5, but had to revert that part of the behavior in 4dc67c0. Unfortunately I neglected to document the specifics.

[theory]

Interesting. I wonder what it could have been!

[Leont]

Interesting. I wonder what it could have been!

I think this happened:

A dist has conditional dependencies (e.g. on OS). Such a condition is true on the author's machine. Then it builds on a machine where that condition is not true (e.g. different OS). When doing a merge the extra dependency will be included even if it shouldn't on that platform.

[theory]

I guess it would require a separate mymeta_merge or something to avoid that issue…

[karenetheridge]

It seems to me that:

We want develop prereqs to show up in both META and MYMETA, so we should keep those in merge_meta / merge_add.

..So only machine-specific dependencies would need to be in mymeta_*, as long as the MYMETA building process starts with merge_meta / merge_add the existing META and then only adds on what it sees in mymeta_*.