Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re^2: Module::Build users -- please use the "traditional" create_makefile_pl option

by perrin (Chancellor)
on May 18, 2005 at 18:27 UTC ( #458372=note: print w/ replies, xml ) Need Help??


in reply to Re: Module::Build users -- please use the "traditional" create_makefile_pl option
in thread Module::Build users -- please use the "traditional" create_makefile_pl option

I don't run the tests when I'm installing known modules in an automated build. I definitely don't want them to be mandatory.

It sounds like the traditional option should just be changed to leave out the optional modules.

Incidentally, META.yml is also pretty annoying, because YAML is so fragile and seems to exist for the sole purpose of thumbing its nose at XML, but that's not a serious problem for me.


Comment on Re^2: Module::Build users -- please use the "traditional" create_makefile_pl option
Re^3: Module::Build users -- please use the "traditional" create_makefile_pl option
by jk2addict (Chaplain) on May 18, 2005 at 18:31 UTC
    I don't run the tests when I'm installing known modules in an automated build. I definitely don't want them to be mandatory.

    This is a loaded question; and doesn't mean I don't do the exact same thing. :-) If you skip the tests, how do you know the install will work as intended?

      I have tests for my application. If those pass, I don't care if the individual module tests pass. I'm installing modules that I know on an OS that I have used them on before, so I don't consider it risky.

      But there's another issue too -- some modules have tests that are not meant to be run when installing. These are tests that the developer wrote for development use and that will not work on other machines. So, the assumption that tests should be run on install is not shared by all module authors.

        Whe you say "I'm installing modules that I know on an OS that I have used them on before, so I don't consider it risky.", do you mean the SAME MACHINE that the tests have passed, or the fact that the tests passed on one machine, so install on the other with the same OS should be ok?

        I understand the argument, and agree with it in situations like developer tests vs. install tests, or where tests don't ship with the modules. But surely this is the exception rather than the rule?

        The majority of CPAN modules don't fall into this category and failing 'make test's almost always mean that the modules aren't going to work as expected and really should just as well be considered build failures.

        For those who didn't want to always run the tests during 'make' or 'Build' there would always be the command line option to not run tests.

        I'm sure I'm in the minority, but I always get mixed signals from the people more important than I in the community about it. Everyone likes to say that having makeing and using tests is of the utmost importance; and everyone like to jump on on the "did you actually run make test" bandwagon when someone reports a module malfunction, yet running the tests is still an optional proposition for the person installing the module. I've always thoug (in the case of most CPAN modules that ship the tests as part of the dist) that a test failure should constitute the same as a build/make failure; and as equals; tie them together.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (10)
As of 2014-10-23 13:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (125 votes), past polls