Perl-Toolchain-Gang/Module-Build — comment on commit 886abd6b50511cc3183162817cae0fdfa18f060f
File:  line 0
By Leont:

> Given the current reality of how .modulebuildrc mirrors the behavior of the command line and includes the special case of Build.PL, the documentation is handing the user a flawed method of setting install paths. Setting default install paths in Build_PL works just like passing them into perl Build.PL which is the safer way of doing it.

That this is working at all is contrary to the documentation IMO (though it's not lacking ambiguity) and common sense (if it did essentially the same as \*, why would we have it?). Configuration options for Build_PL should only affect the Build.PL stage AFAIK, and only the actual command-line arguments should affect later stages. I consider this a bug that should be fixed, not something that should be documented as a solution for anything.

Most importantly, .modulebuildrc despite it's name is a file shared by all Build.PL implementations. Having an entry like this that will work in one, yet fail in all the others (possibly including a future version of Module::Build) is a recipe for pain. This sort of stuff *must* be coordinated first, and should probably be updated in the [spec](https://github.com/dagolden/cpan-api-buildpl/blob/master/lib/CPAN/API/BuildPL.pm) before it's updated in Module::Build.

> Setting default install paths at install time silently overrides what the user might have passed to perl Build.PL and that's just wrong. Furthermore, the install paths are not just used by the install target. In a perfect world they should be, but I'll bet that's not the reality for many CPAN modules. Why tempt bugs?

I agree with you there. If I understand correctly what you're doing, you can use an \* pseudo-action in the configuration file to achieve the same thing in a much cleaner way. I would suggest that as a solution (in fact, I would suggest everyone to only use '*' for most .modulebuildrc stuff, but that's another discussion).

> If you want to discuss changing the order of how command line and modulerc defaults are handled to avoid the defaults blowing over perl Build.PL arguments, open an issue about it.

Sounds like a good discussion for Paris.

> We shouldn't screw the user with examples based on how we'd like it to work. They have to reflect how it works right now.

We shouldn't screw them over in the future either just because we've got issues now. We don't want to break their configuration at some point in the future, or worse yet be stuck with even more contortions.