Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

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

by ELISHEVA (Prior)
on Feb 25, 2011 at 10:12 UTC ( #890155=note: print w/ replies, xml ) Need Help??


in reply to Re^7: 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?

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.


Comment on Re^8: Do Pure Perl CPAN packages really need to use ExtUtils::Command::MM?
Select or Download Code
Re^9: Do Pure Perl CPAN packages really need to use ExtUtils::Command::MM?
by ikegami (Pope) on Feb 25, 2011 at 19:31 UTC

    If you didn't realize that this whole discussion was about distros where files meant only for build/test should not escape the distro?

    Our discussion was about your claims that M::M has special requirements for test files if they want to use modules that aren't to be installed.

    There are other replies to your OP that might relate to that, but I didn't read those. I already had enough on my hands with this topic.

    ./Build supports all of the above

    You said you wanted something portable though. That's very specific to M::B, so it doesn't mean your own requirements. It's also totally unnecessary if the test script would actually run.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (4)
As of 2014-12-29 04:22 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

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





    Results (184 votes), past polls