make with-configure default for installdeps, or mention it in docs for installdeps

[wchristian]

I just spent half an hour of finding out the following, and would like to see steps taken to spare others this pain:

https://metacpan.org/pod/CPAN::Meta::Spec#Phases documents configure phase as things to be installed before Bpl or MFpl are run. This makes cpanm --installdeps with a cpanfile seem a good step to do before doing either of those.

Currently installdeps ignores the configure phase deps without with-configure set.

However the doc entry for installdeps does not mention this.

And the doc entry for with-configure says it's experimental, but does not explain why.

---

So i'd like to see one of the following happen:

1. Make with-configure default for installdeps.

Or

2. Document in the installdeps entry that not all phases are taken into account and how to add the missing phases.

Bonus: Remove the mention of experimental, or add docs as to why it's experimental.

Which of these makes more sense?

[miyagawa]

the thought behind this behavior is:

• what --installdeps does is to install dependencies, not more
• configure phase is only required if you need to figure out the dependencies by running the configure script
• which is not the case if you have cpanfile

including configure phase by default goes contrary to this thought process. I understand the definition of "dependencies" are not always the same depending on the use case. I can probably take a doc patch to explain the default phases for --installdeps option.

[wchristian]

Your thinking there seems to apply only if the dependencies are pure perl. The specific module i ran into this problem with was OpenGL::Modern, which must work out what hardware and OS it is on, which libraries are provided by the system and configure the build phase compilation of things accordingly. Did i make some logic error here? Does your logic about installdeps intentionally exclude such dists?

In any case, to not be held up by that conversation i'll prepare a doc patch.

[wchristian]

Doc patch done, also discussed it at length with Grinnz on IRC.

An important part of the puzzle here is that we want to run an XS dist on travis and want to use cpanm to handle installing the deps to build the thing, so we can test it. Normally --test-only would be fine and useful for this, but for travis reporting (errored/failed) the build and test steps need to be separate, so we can't just run test-only on the current dir.

As such, the optimal solution here would be the addition of a --build-only command that's an alias to --test-only --notest.

Personally, for the sake of completeness, i'd also support the addition of an unopinionated --installalldeps or --installdepsall, to have a command available that doesn't carry any potential to surprise any user, and doesn't require users to go on exploratory doc diving just because they're doing something that isn't done by the majority of cpan modules.

[miyagawa]

Your thinking there seems to apply only if the dependencies are pure perl.

I think you're confused. XS dependencies are also configured, built and tested correctly. The only item being skipped here is the configuration of the main target of the command, which is the current directory if you run it with cpanm --installdeps . (the current directory argument).

[miyagawa]

As such, the optimal solution here would be the addition of a --build-only command that's an alias to --test-only --notest.

If you're building an XS dependency which requires the running of full blown configure, build and test, then you're right that --installdeps is not designed for that.

Again, the mismatch here is that with cpanfile, the classic Makefile.PL/Build.PL should not be required to run - except in a case where the dist itself needs to be configured, either due to dynamic dependencies, or dynamic system configuration such as XS.

There's a CPAN meta spec directive dynamic_config, but for historical reason, this metadata cannot be trusted in most situation. (There's an experimental branch I opened about 2 years ago to skip the entire configure, build, test process when dynamic_config is 0)

One compromise can be made so that --installdeps . could detect the existence of META.json and dynamic_config, and if it's explicitly set to 1, then configure can also be added. But I wonder if that just further complicates the situation because all of these are fully dynamic anyway, like you suggested.

[wchristian]

I think you're confused. XS dependencies

Sorry for stating that unclearly. I didn't mean dependencies that are XS, but dependencies that are required often by XS dists; binary libraries in the system itself, e.g. glew, freeglut, etc.

[wchristian]

Also it turns out --test-only --notest not useful, as it skips cpanfile, and could only work usefully with released dists that contain meta files.

[wchristian]

As for meta files, having those present would be counter-productive, as it means cpanfile cannot serve as the canonical and only source of dependencies in the dist, and would mean a dev has to know, and spend extra effort, on maintaining them via manual edits of build tools runs.

[miyagawa]

would mean a dev has to know, and spend extra effort

I agree to your sentiment, but in most of the cases, we have a way to auto-populate META files and Makefile.PL/Build.PL using tools like Dist::Ziilla, using cpanfile as a canonical source. The confusion just comes around when your CI is invoked directly in the repo, before the authoring build process is even run.

I wrote a piece about this about a year ago to improve this situation https://gist.github.com/miyagawa/5028262 but as with everything else, this requires a consensus and efforts across the larger group of the ecosystem, and it has not happened.

And in general, META.json contains way more information than cpanfile. My build tool, Dist::Milla, by default dumps META.json into a repo so that cpanm in CI run can make use of both META.json and cpanfile.

[wchristian]

OpenGL::Modern doesn't use a build tool beyond EUMM. And even with a build tool extra human intervention is necessary since it's easy for things to get out of synch if it isn't run on each commit. That's why i see it as important to have cpanfile not only be canonical, but also the only source of deps. META files are a fragile and expensive workaround imo.

The build tool could also be run on Travis, but that then requires the extra effort of building and installing and testing that on travis.

Also generally it would be helpful if XS dist authors could just tell their collaborators "run cpanm --one-command ." to develop on your system, which right now isn't possible for them, even though it's possible for >90% of the rest of the population.

In short: I see a special case here with no discernable upside, and no strong* downside if it weren't there. (* some extra dists installed, usually a small set of them too)

Edit: That proposal goes some ways beyond what i'm able to consider deeply at the moment. Sorry.