2 ms·

An example from the top of my head: compose = sh.docker.compose.bake('-f', 'deploy/dev.yml') … compose.down() … compose.up('--force-recreat

An example from the top of my head: compose = sh.docker.compose.bake('-f', 'deploy/dev.yml') … compose.down() … compose.up('--force-recreate', '-d') I feel this is a major improvement on top of Makefiles + shell commands in them. Nice API _matters_; it is ergonomics and therefore productivity. You can specify `_out=rich.print` and it will work but AFAIK it won't scrape ASCII terminal formatting characters. I had to fix these characters in my `sh` based scripts but do not consider that as a big deal.

theamk 3y ago
Doesn't the snippet above hide the errors and warnings (since I do not see any code to print them)? Does not seem very ergonimic to me.
- yeti-sh 3y ago
  No it does not, in fact; errors or warnings will pop up as an unhandled exception and print: - command actually executed, - snippet of stdout - and snippet of stderr. They can be handled using standard exception techniques.
  - theamk 3y ago
    Isn't that only for failed commands? so if command succeeds with warnings, or if if fails, but the retries and passed, ghen you get no output.
    - yeti-sh 3y ago
      The exception is raised if the command returns a non-zero error code. If it returns a zero error code then the return value of, say, compose.up() contains the command's stdout. In addition stdout can be redirected to a file, or to another command, or to a callable, — which will be called for chunks of stdout while the command is in operation.