Re: [PATCH] t5150: skip request-pull test if Perl is disabled

[Jonathan Nieder <jrnieder@gmail.com>]

Jeff King wrote:

> Hmm. I don't think that technique gives complete coverage. There are
> other scripts (e.g., filter-branch) that call a bare "perl" (not
> PERL_PATH), which presumably pass the tests even though they'd break in
> a real-world system without perl. In fact, many scripts used to do this
> before fcb06a8d54 (use @@PERL@@ in built scripts, 2013-10-28). I don't
> think the effects on NO_PERL were really considered there; it was more
> about finding the right perl.

Oh!  Thanks for looking deeper.

> I think NO_PERL has historically mostly meant "do not build or install
> perl scripts", and not "everything ought to run fine without perl".
> We've generally assumed you can run vanilla perl snippets from the
> command line the same way you'd run awk or sed (and the tests use this
> extensively, which is why you have to set PERL_PATH again to run them).

Right.  PERL_PATH and NO_PERL are more orthogonal than I had thought.
So this is

  Not-Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>

--- the patch shouldn't be applied as is.

> That said, most of those casual uses of perl in actual built scripts
> have gone away because the shell scripts have gone away. It looks like
> filter-branch, request-pull, and instaweb are the last holdouts. So
> maybe we should be treating NO_PERL as disabling those scripts, too.
>
> But then, should we be doing more to make it clear that those scripts
> are broken in a NO_PERL build? Who knows what happens if you run
> filter-branch without any perl available?

Agreed: if we want to follow this approach, we should install stubs in
place of those scripts when NO_PERL=YesPlease.  Will say more about
this in a separate reply.

Thanks for catching it,
Jonathan