Conversation
| case exit_code of | ||
| ExitSuccess -> return () | ||
| ExitFailure r -> processFailedException "callProcess" cmd args r | ||
| callProcess cmd = callCreateProcess_ "callProcess" . proc cmd |
There was a problem hiding this comment.
Technically I would be in favor of:
- Implementing this in terms of
callCreateProcess - get rid of
callCreateProcess_ - state in the documentation that this is an alias for
callCreateProcess (proc cmd args)
However, technically that is a breaking change, as it will change error messages. Not sure how big of an issue that is, but when readCreateProcess was introduced back in 2015 error messages did change, so there is some precedence at least.
From a users perspective, you don't really want a whole bunch of different functions that are all slightly different and are implemented in terms of internal primitives. What you want is:
- General functions that are flexible
- Specialized functions that are implemented in terms of those more general functions
Sadly, process is very far from this ideal.
There was a problem hiding this comment.
And presumably for callCommand too?
I don't really have an objection to this. It makes a lot of sense and I personally don't feel strongly about just the function name changing in the error message.
There was a problem hiding this comment.
Looks like we need spawnCreateProcess too!
sol
force-pushed
the
dry
branch
2 times, most recently
from
485d512 to
c341f96
Compare
|
Thanks, this is very nice. I took the liberty of breaking into tiny commits so I could see what was going on. |
for callCreateProcess
|
There are failures only on old GHCs on MacOS. At some point I might dig into why, but they shouldn't block this PR. |
2 participants
readCreateProcesscallProcessandcallCommand