Sadly, despite all this back and forth I still don't get your point.

Because having to use bash -c'cd .. ; ./Build test' to run a single test is not right.

M:B lets the distro writer put custom paths in @INC to make the automated build-test-install cycle run more smoothly. You are not an automaton. If you don't want to take advantage of the fact that M:B automatically puts the right paths into @INC, then put the paths yourself into PERL5LIB. Then you don't need to cd to any directory at all. Nor do you need to run "./Build" or make or any other harness.

If your script wasn't buggy in the first place...

This is post is not about buggy scripts and never has been. The issue at hand is how to configure M:M so that files that are needed for testing/building are available in @INC but don't end up getting installed at runtime.

M:B manages to provide a 100% portable way to put such files in a distro subdir of the distro-writer's choosing. It ensures that they will be available for test/build but does not install them to system/site directories after testing is complete. They stay put in the distro.

M:M is very rigid about how to handle such modules and it forces programmers into what I consider problematic or questionable practices:

• Compensating for the hardcoded @INC by putting "use lib" all over test scripts raises separation of concern issues.
• Rooting "build/test but not runtime" modules in the distro root is just ugly and interferes with automation.
• Adding a line to the Makefile to insert a directory into PERL5LIB is not universally portable.
• Running tests via a test harness (test.pl) and moving tests to "tests" enables "make test" to work fine but borks "./Build test". The tests all run and pass, but Build never sees the TAP output. Maybe there is a solution to this, but I'm still looking for it.

If you really want to be helpful, propose a solution that uses ExtUtils::MakeMaker to run make file commands, doesn't interfere with M:B, is 100% portable, respects separation of concerns (no confusing operational code with the configuration needs of a specific environment), and ensures that files meant for build/test but not runtime never leave the distro.

then put the paths yourself into PERL5LIB. Then you don't need to cd to any directory at all. Nor do you need to run "./Build" or make or any other harness.

Why would the caller need to know anything about the internals of the script to run it? Again, this is not a solution.

Compensating for the hardcoded @INC by putting "use lib" all over test scripts raises separation of concern issues.

No, you don't need to add any use lib for it to work. Saying it 5 times doesn't make it true.

M:B manages to provide a 100% portable way to put such files in a distro subdir of the distro-writer's choosing.

So does M::M. The same mechanism, in fact.

propose a solution that [...] ensures that files meant for build/test but not runtime never leave the distro.

I didn't know that was a problem.

propose a solution that uses ExtUtils::MakeMaker to run make file commands, doesn't interfere with M:B, is 100% portable, respects separation of concerns (no confusing operational code with the configuration needs of a specific environment), and ensures that files meant for build/test but not runtime never leave the distro.

Quite demanding from someone who states that it's ok to require intimate knowledge of the distro's file layout to run a test script.

I didn't know that was a problem.. quite demanding from someone who says it's ok to require intimate knowledge of the distro's file layout.

Sigh. If you didn't realize that this whole discussion was about distros where files meant only for build/test should not escape the distro, then what did you think it was about? The second paragraph of the OP says "When you have libraries that are used by the build/test process but not part of the runtime code..."

There is nothing to discuss in the simple case where everything needed to build/test also gets installed. For that scenario M:M and M:B do indeed both work the same way: just put everything in "distroRoot/lib". The conventions and capabilities of M:M and M:B only begin to diverge once you introduce modules needed for build/test but not runtime.

I don't think a downloader should need to have intimate knowledge of a distro anymore than you do, which is exactly why I want a clean, portable way to put paths into @INC for them when there are reasons why Perl modules can't go into /lib (i.e. they are needed for build/test but should not leave the distro.)

Just to be clear, I'll make myself even more demanding and add some additional conditions to the requirements you already consider too demanding:

propose a solution that uses ExtUtils::MakeMaker to run make file commands, doesn't interfere with M:B, is 100% portable, respects separation of concerns (no confusing operational code with the configuration needs of a specific environment), allows a user to verbosely run individual tests without knowing what libraries internal to the distro are needed to run the tests, and ensures that files meant for build/test but not runtime never leave the distro.

But it doesn't change a thing. ./Build supports all of the above (see the --test_files, verbose=1 command line options discussed in Module::Build). It is all right there in the docs - no source code diving needed.

Heck, it will even let you run ./Build from any directory in the system. No cd'ing needed. So if you really want to run t/the-only-test-I-care-about.t from your home directory rather than distro root, just type $distrodir/Build test --test_files=t/the-only-test-I-care-about.t verbose=1. Your concerns that M:B would make you do something yucky like know the layout of the distro or cd'ing to run a single test are unfounded.

If it is too much to ask a makefile backed by M:M to also do all of the above, I'd tend to say that the problem lies with M:M and not with the wishlist. If it is not too much, then present your solution. That wishlist contains nothing but the expectation that M:M allow distro developers to conform to best practice (portability, separation of concerns, etc). If you consider that unreasonable, we will simply have to agree to disagree. I'll read what you write, but I have nothing further to say.

To me, striving to support best practice and being willing to point out when software fails to support it, is absolutely necessary for the long term health of the Perl ecosystem. Lowering expectations to match the capabilities of a beloved tool (M:M) is counter-productive.