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

[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.

[ikegami]

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.