On Wed, Jul 31, 2024 at 03:24:01PM -0700, Junio C Hamano wrote:
> > +start_socks() {
> > + mkfifo socks_output &&
> > + {
> > + "$PERL_PATH" "$TEST_DIRECTORY/socks4-proxy.pl" "$1" >socks_output &
> > + socks_pid=$!
> > + } &&
> > + read line <socks_output &&
> > + test "$line" = ready
> > +}
> > +
> > +test_expect_success PERL 'try to start SOCKS proxy' '
> > + # The %30 tests that the correct amount of percent-encoding is applied
> > + # to the proxy string passed to curl.
> > + if start_socks %30.sock
> > + then
> > + test_set_prereq SOCKS_PROXY
> > + fi
> > +'
>
> Making it a regular test_expect_success would mean GIT_SKIP_TEST
> mechansim can be used to skip it, which is probably not what you
> want. Can't this be a more common test_lazy_prereq, perhaps like
>
> test_lazy_prereq SOCKS_PROXY '
> # useful comment about 30% here ...
> test_have_prereq PERL &&
> start_socks %30.sock
> '
>
> or something?
I think Ryan picked up this approach from my earlier mail. And the
reason I suggested doing it this way is that the prereq test has an
important side effect: it creates the socket and starts the proxy
server!
I think lazy prereqs only make sense when their only output is the
yes/no of whether we match the prereq. And then we don't care when or
how often they are evaluated. I do think things would work, assuming the
proxy server then can serve multiple tests. It just feels weird, and
doing it more like the git-daemon/http tests made more sense to me
(though those ones do not even do their work inside an expect block).
If we did it in a lazy prereq I think you'd need to munge the path, as
the lazy prereq operates in a throwaway directory (so the %30.sock would
get removed before we can use it in the next test).
-Peff
