Jeff King <peff@xxxxxxxx> writes: > 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! Ah, OK. > 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. Once the prereq test is attempted the result is cached (that's the whole point of lazy prereq mechanism) so we won't see multiple sock proxies spawned. > 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). OK. That's fine. It is probably not a good fit for the pattern. > 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). True.
