All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

As far as I'm aware, that doesn't ensure that Module::Build is upgraded, it just crashes the installer with an obscure error message that will be buried somewhere in the middle of 3000 lines of CPAN.pm output.

If you are doing a one-off install and running Build.PL directly, and you understand error messages, then maybe in that small case it's good enough. but of course almost nobody does that.

As for the build_requires dependency, the Build.PL needs to be run in order to confirm that

I don't have a distribution with a custom Module::Build subclass where the build_requires trick won't work, but if the use line doesn't, how about printing the same error message? M::B and CPAN.pm communicate somehow, so I see no reason why following that protocol won't make this scheme work.

CPAN.pm and CPANPLUS both somehow detect when a distribution has unfulfilled dependencies. Both offer to install those dependencies.

Both MakeMaker and Module::Buildsomehow indicate unfulfilled dependencies to the installer. I don't know if it's screenscraping or an API or whatever. I skimmed CPAN.pm this morning, but couldn't find it in two minutes.

Now if there's an API or if there's a particular error message being scraped and detected and

There are three different conceptual code elements involved in a distribution.

The Installer.

The Build Process.

The Installed Module.

CPAN.pm detects the Installed Module has unfulfilled dependencies, and is informed of them by executing the installer.

This can theoretically be shortcut for static dependencies in a setset of cases, but in practice nobody ever sets that flag and so the installer MUST be run.

CPAN.pm detects the Build Process has unfulfilled dependencies, and is informed of them by executing the installer.

This can theoretically be shortcut for static build dependencies in a setset of cases, but in practice nobody ever sets that and so the installer MUST be run.

CPAN.pm does NOT detect the dependencies of the installer.

The idea that you can execute a program in order to find dependencies needed in order to execute the program is logically impossible. It is a circular dependency.

The installer MUST be able to run correctly and without crashing.

Once run, it reports to CPAN.pm (by modifying META.yaml to contain data tailored for the local host, or via Makefile parsing) the dependencies required for the build phase, and for the distribution at run-time.

In a vanishingly small number of cases, the META.yaml file has a flag enabled which says that the contents are the same on all platforms, and that the installer does not have to be run to determine dependencies.

And those cases are irrelevant for the purposes of designing Module::Build's back-compatibility feature.

There are only three solutions to this problem.

1. You bundle the installer, and never change the API (MakeMaker)

2. You bundle enough functionality to work regardless of the environment (Module::Install and Windows installers)

3. You make the installer FORCE upgrades to itself. (Windows Update, Steam)

This is fairly straight forward stuff.

Ken understands this quite well, and Module::Build may well be stealing some tricks from Module::Install down the track.

I suggest you read more into how CPAN.pm and the installers work together, and it should become quite clear why the current situation isn't enough.

I am suggesting that, in those cases where the installation program depends on a specific minimum version of the installer module (and in several years of maintaining a couple of dozen of publicly available modules, I can think of one case where this was necessary), the author should do precisely that.

There already exists a perfectly good mechanism to mark and install dependencies through both of the installer shells. Why complicate the process?

I am suggesting that, in those cases where the installation program depends on a specific minimum version of the installer module (and in several years of maintaining a couple of dozen of publicly available modules, I can think of one case where this was necessary), the author should do precisely that.

That is certainly an acceptable partial solution for the cases where dependencies are static, and one that individual authors can use today.

I mean, "Authors of distributions that rely on a specific version of the bundling module should be able to mark that dependency in such a way that the installer can detect that dependency immediately." Whether that means adding a new entry in META.yml or running a little bit of code at the start of Build.PL or Makefile.PL, I don't particularly care.

The latter seems easiest.

The point is, I believe you can run just enough of the bundling program to flag an

I can see a number of ways in which it could be done, a few of which you have described.

It's just that the situation remains that despite what should be possible, it still hasn't been written, and what I try to keep pointing out is that there needs to be, and that whatever the solution is, it needs to be completed and working before we can consider M:B to be stable and suitable for the core.