use Perl

• aol! (Score:1)

  by jmason (3282)

  I do this too, on some of my modules. A bit more simply, though -- instead of inferring whether the author tests should be run automatically, I just invoke them separately using something like:
  
  prove -v author-tests/*.t
  
  to be honest, the additional legwork of one commandline doesn't bother me ;)
  • Re: (Score:1)

    by Aristotle (5147)

    You can go one better: author tests are mostly things even the author doesn’t want to run all the time, but definitely wants to run before he ships a new release. So if you’re using Module::Build, you can override the dist and/or disttest action(s) to run your author tests automatically. I find this a better hook than RJBS’s, and unlike your suggestion you can’t forget to run the tests – so no brown bag bugs. :-)
• "It's really quite simple..." (Score:2)

  by bart (450)

  Module::Install has a pretty simple idea of whether you're the author. If an ./inc directory doesn't exist when you run the Makefile.PL, one is created, and all the required Module::Install code it put into it. Then, a directory is created called ./inc/author. If that directory exists, you're the author. If it doesn't -- because ./inc existed already when you ran the Makefile.PL, because you got the whole thing in a tarball from the CPAN -- then you are not the author.

  WTF?? I must have a different idea than you of what constitutes a simple test, then. Way too much voodoo!

  I'd rather try something like this: if you're a CPAN author, you set an environment variable with your CPAN ID. For example, for you, you'd set it to "RJBS". At the time to run the tests, this author testing module test to see if $ENV{CPAN_ID} is set, and if it is, see if it's set to the name of the author of this particular module. Only then, you will be considered to be the module author, for this mo
  • Re: (Score:1)

    by rjbs (4671)

    No, that wouldn't work for me.
    
    I work on a number of distributions that have multiple authors, maintainers, and/or contributors. It would foolish if they had to set CPAN_ID=RJBS when working on my code. I'd also have to put my CPAN id somewhere in my code, either ina ll the "author tests" or in the Makefile.PL as an argument too some author test runner. That would need to be updated when the module changed hands.
    
    I could set I_AUTHOR_Module-Starter=1 and have everyone who works on it do the same, but some

    --
    rjbs
  • Re: (Score:1)

    by Yanick (3196)

    At the time to run the tests, this author testing module test to see if $ENV{CPAN_ID} is set

    Personally, I prefer to have all my modules listed in TEST_AUTHOR (E.g., export TEST_AUTHOR=My::Module,My::Other::Module), and have the check be

    if ( grep { $_ eq 'My::Module' } split ',' => $ENV{TEST_AUTHOR} ) {
    ...
    }

    That way, I have only one environment variable to take about, and it's not tied to me but rather to the modules of interest.
• go ./xt! (Score:1)

  by Eric Wilhelm (6389)

  Now if we can just get some metadata about the tests hammered into a standard...
  
  >I really need to start using ShipIt or Joseki
  >or something. I'm afraid I will end up writing
  >my own.
  
  If you want to ride along, the CPDK has a publish_module script. I haven't turned it on itself yet, but I've been using it for several months now.
  
  http://scratchcomputing.com/svn/CPDK/trunk/ [scratchcomputing.com]
• manifest? (Score:1)

  by pfig (5969)

  unrelated to perl, but is there a reason why you don't generate the tarball from the manifest? that way the metadata files from os x wouldn't get in there.

  --
  bgp is for those who can't keep it static long enough
  • Re: (Score:1)

    by rjbs (4671)

    I "make dist." Maybe the manifest got them in it from a "make manifest" with an incomplete MANIFEST.SKIP.
    
    Either way, easy to fix.

    --
    rjbs