Re^3: Do Pure Perl CPAN packages really need to use ExtUtils::Command::MM?

[ikegami]

ExtUtils::Command::MM::test_harness adds $(INST_LIB), i.e. blib/lib, and $(INST_ARCHLIB), i.e. blib/arch to @INC. It has no provision for adding anything more to @INC

Exactly. Your claim that there's something special about the project root is completely false.

I simply don't buy that it is a "good thing" to go around coding "use lib" statements in every single .t file.

It's a necessary thing, not just in .t, but in all scripts that use uninstalled modules. If you don't, Perl won't find them. If the module isn't somewhere where Perl would normally look (e.g. the directory in which the script resides), you need to tell Perl where it is.

No idea why you bring up CPAN and legal protections.

First, it means that I have to go into every file I want to ship and edit it to have that line.

No, just the scripts.

Secondly, these support libraries are used in a lot of different projects

Straw man. If Perl can find your libraries, they don't need to tell Perl where to find your libraries.

Secondly, if you have a module that used by multiple projects, it's silly to copy it into each project and adjusting @INC to find that copy. Install the module.

I have no need of it when I let Module::Build build the project.

So you're proudly claiming that one needs to use a giant harness to get your test script to work properly, ignoring that it fails the rest of the time.

I am not proposing doing away with Makefile.PL.

I didn't even address your proposal. I just corrected the false claim that only 3% of testers try to run Makefile.PL.

To address the proposal: It's a lot of work and you claim introduces problems, while you can get the desired effect by simply adding inc/ to the harness command. And your test script still won't run outside the harness.

Before you reply that you don't expect your test scripts outside of Module::Build, realise there's no problem if that's true.

[ELISHEVA]

our claim that there's something special about the project root is completely false.

Huh? Project root is in there too. It just isn't added by the test target because it is already there. Its specialness comes from the fact that it is the only path within the project area that (a) is in the hardcoded @INC and (b) does not include files that will be installed at runtime. Thus it is the only directory within @INC that can be used for libraries that are needed by tests/setup but should not be installed to INSTALLDIR after all tests pass. If I want to avoid splattering "use lib" all over the place I have to put such files in root. Nothing I have said is remotely false.

So you're proudly claiming that one needs to use a giant harness

Huh? Who said anything about a giant harness? Because I can add one line to Build.PL and Module::Build generates a ./Build file that inserts a path in @INC, that counts as a giant harness?

My automated build process manages to configure itself without splattering "use lib" all over the place as well. Automated build processes are evil giant harnesses?

In my day to day work area code is not divided into separate source trees for each project, nor for each packaging tool. There is a single source tree for everything. "use lib" is completely irrelevant and unnecessary. If I want to run a test I place myself at the source of the tree and run "prove". If I want to run a script, I place myself at the source of the tree and type the script name, "Foo/Baz.pl". Is prove a giant evil harness? Is standing at the root of the source tree?

The only thing I've claimed is that splattering "use lib" or Find::Bin + use lib all over my scripts reflects the needs of a specific run environment - that created by ExtUtils::MakeMaker. It is completely unnecessary if those tests are run in the environment created by Module::Build. "use lib" is completely unnecessary in nearly any other environment I run my test scripts. Thus I conclude that putting that code in every script violates separation of concerns and constitutes programming to the tool. You have not yet addressed those two issues.

I've used lots of different build tools and installers over the years and MM strikes me as the only one that expected me to modify my source code to accommodate it.

ignoring that it fails the rest of the time.

When you equate difficulties with MM to "the rest of the time", I can't help wondering whether you've decided that the only "real" tool is MM and any other successful run of my tests is irrelevant. In every other environment, including a makefile backed by Module::Build they run fine without splattering "use lib" all over my scripts. They'll run fine under ExtUtils::Command::MM if there is a portable way to put "projectroot/inc" into @INC as well.

Update: Removed some stuff that was really besides the point.

[ikegami]

I didn't mean to start reading this now, since I got to go, but the first sentence caught my eye.

Huh? Project root is in there too.

My test shows differently. That's apparently not something you can rely on.

[ELISHEVA]

On my machine "." is in @INC. On tye's machine as well. What about yours? tye relies on "." himself within his CPAN modules (last night in the cb after you left).

In an automated CPAN build, it is my understanding that "make test" is run at the project root. The list of files that the generated Makefile file passes in the test target by default (if you don't configure "test") uses paths relative to project root, implying that it expects to be run with cwd set to the project root. The "disttest" target in the makefile, which is supposed to emulate testing in a distribution cd's to $DISTVNAME before running tests. Are you aware of circumstances where CPAN runs "make test", "make install" from some other current directory?

[ikegami]

Huh? Who said anything about a giant harness? Because I can add one line to Build.PL and Module::Build generates a ./Build file that inserts a path in @INC, that counts as a giant harness?

I did. Because having to use bash -c'cd .. ; ./Build test' to run a single test is not right. It runs all the tests instead of the one you want, and I think it doesn't even give the full test output.

Automated build processes are evil giant harnesses?

I never said evil. Just inappropriate for some tasks.

I've used lots of different build tools and installers over the years and MM strikes me as the only one that expected me to modify my source code to accommodate it.

It doesn't expect anything of the kind. If your script wasn't buggy in the first place, you wouldn't have to modify it.

In short, there are many ways to do things and many different environments that scripts run in. One should not assume that everyone who does something different than your way or MM's way is doing something evil and bad (technicaly speaking) the way you just did with me.

That's my point. You're assuming that it's M::B vs M::M, but it's not. The solution to your script being broken even in a M::B distro isn't to change M::M.

[ELISHEVA]

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.