Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

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

by ikegami (Pope)
on Feb 24, 2011 at 18:06 UTC ( #890032=note: print w/ replies, xml ) Need Help??


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

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.


Comment on Re^5: Do Pure Perl CPAN packages really need to use ExtUtils::Command::MM?
Download Code
Re^6: Do Pure Perl CPAN packages really need to use ExtUtils::Command::MM?
by ELISHEVA (Prior) on Feb 24, 2011 at 23:52 UTC

    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://890032]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (8)
As of 2014-12-26 10:28 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (171 votes), past polls