[bsimpson]

Also, `>> 'some-cmd --with --args'` is code that's more likely to end up in a deployment script than in a production app. Less likely to be a project that's being edited by many people at once, served to end users, etc.

I respect and often agree with the parent's hesitation to introduce inessential dependencies, but the cost/benefit of making a shell script more comfortable to read/write is very different than that of adding a mystery brick to the foundation of your app.

[nrclark]

Deployment scripts are production code, same as whatever you're deploying. If your CI/CD docker images break, you're just as stuck as if your payload breaks.

I totally see the benefit of moving complex shell logic to Python (and still calling some shell helpers) but that doesn't mean you need to have a whole extra dependency for it.

You could write a two-line function that wraps subprocess.Popen.communicate (or subprocess.check_output), and use it instead for 90% of the benefit.

If the argument is "I don't want to learn it", or "too much effort", then I'd ask - is saving 15 minutes one time during development really worth a permanent dependency?

I remember Leftpad, and the lessons that it taught.

I've also had to deal with codebases where the build kept breaking because a large team of developers all Pip-installed whatever they wanted. A package here, two packages there. Overall a maintenance disaster, and you'd be surprised at how often those dependencies outlasted any code that used them.