-
Notifications
You must be signed in to change notification settings - Fork 846
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
stack solver
fails on Windows with streamingProcess error
#723
Comments
I just reproed this on Windows, investigating. |
After some investigation: it appears that the command line arguments are somehow triggering this. |
It seems that, on Windows, the large number of arguments causes the process package to give the incredibly misleading error message: C:\Users\chris\AppData\Roaming\local\bin\cabal.exe: streamingProcess: does not exist (No such file or directory) This workaround isn't just a hack, but a good thing: putting constraints in the config file is an improvement in general, so I'm happy to keep it. Nonetheless, this is something that should be fixed at the process package level.
This should now be resolved. The problem does in fact seem to be large argument lists to System.Process functions, which I'll investigate now separately. My workaround- which is actually a better architecture anyway- is to move the package constraints into a config file. Rerunning from master should solve the problem, please ping if it doesn't. |
I've opened up haskell/process#37 to track the upstream bug. |
On Windows system,
stack solver
fails with this error:The path stated in the error is the correct path for
cabal.exe
; it exists at that location, and works correctly withstack exec
. The same error appears when cabal.exe is located elsewhere, with the reported path adjusted accordingly.The failure mode seems to occur under all circumstances: in or not in a project directory, with or without a
.cabal
file present, etc.I spent some time looking into the problem a few days ago, with no useful result. If the error message is generated by cabal itself, this may (or may not) be an upstream bug.
(The fix for #712 has no effect on this problem.)
The text was updated successfully, but these errors were encountered: