[darcs-devel] my problems with tests that run ssh/curl
ganesh at earth.li
Sun Jul 26 15:33:50 UTC 2020
>> I've played with it before, but it's quite unnative - it's more like
>> Docker-lite than something that is genuinely integrated with the Windows
>> ecosystem. So in particular I'm not sure that it would test what our
>> users would actually be doing when using darcs outside WSL.
> Hmm, yes. While WSL1 was more like what wine was for Linux, it seems
> that WSL2 is more like a container, running a real Linux kernel.
I was actually referring to WSL1, and hadn't even noticed WSL2 now
exists :-) It actually looks like WSL2 might be a decent replacement for
my current VirtualBox setup, especially if I can use NixOS on it at some
> However, I wonder if that really matters, assuming the darcs under test
> is the native darcs.exe compiled on and for Windows. In some sense,
> using bash scripts means we already test the wrong thing. For instance,
> our test suite does *not* test that darcs behaves correctly when it gets
> a native Windows path ("C:/...") as an argument. This suggests to me
> that using WSL for testing might not be (much) worse than using cygwin.
I think our test suite does test that, because of msys's path
(I think the same is true for cygwin, but I haven't used that for a while).
> I also wonder what your build environment is on Windows. And how (and
> if) you are actually using the native darcs.exe (i.e. via powershell or
> cmd.exe) for anything, so we have at least anecdotal evidence that it
> does the right thing there.
I'm not sure quite what you mean by build environment, but I do
basically everything from the msys/mingw64 shell including running cabal
However I am pretty confident that the darcs.exe that gets built is a
native binary (not depending on msys itself), and I do occasionally run
it from cmd.exe or powershell when investigating something where I
suspect msys could be confusing things. For example the recent issue
with the tests for Cyrillic characters.
> for how to run a native windows binary on WSL.
Thanks - I see there's a mechanism for path translation via environment
variables but I'm unclear how this works from the command-line.
> That's what I meant. If it was slow but just tolerable before than why
> has it gotten so much worse?
I've now tried the tests after rebooting and on another computer, and it
looks like the primary culprit is indeed the spyware. It was much faster
in both cases where the spyware was out of the picture.
The problem for me is that most of the time the situation is difficult
to avoid. Even before when I normally worked from the office there were
various reasons to want to login from home. I could perhaps switch one
use case or the other to a VM but that has its own workflow problems.
I've wondered before about redoing the test harness as a single process
in Haskell, calling darcs as a library. This would get rid of both the
process creation overhead and the various compatibility issues between
Windows and Linux for random external commands. On the other hand we
would be moving further away from testing the executable "naturally".
It would also be a lot of work to migrate completely, though we could do
it incrementally and get partial benefits along the way. The darcs
library would also need some work to make it feasible.
I am not at all convinced we should do it, nor that I would actually get
around to it anyway. But if can decide in principle if it would be
reasonable, then it at least could be there as an option for the future.
More information about the darcs-devel