[rekwah]

I wrote a pretty significant process wrapper in python at $PREVIOUS_JOB. The problem I have with these loose wrappers around subprocess is that they're, imho, solving the wrong problem. Or, maybe better put, not solving _enough_ of the problem.

Imagine writing a wrapper for "grep". It may work in one environment, but if you need portability, you're going to quickly realize that there are nuances in implementation and the actual calling interface. Now you're handling branching logic in your application code based on platform, version, etc.

Interfacing with a command line tool shouldn't be thought of much different than a remote HTTP/ReST API talking text/plain instead of application/json. You're looking for your "client wrapper" to handle argument validation, parsing, versioning, etc.

[marmaduke]

> much different than a remote HTTP/ReST API

does that make subprocess module like urllib, and these wrappers like the ubiquitous requests package?

I think it's harder than you say: a given tool like grep has an API the size of an entire website, and then depending on usage, has different usage patterns which different optimizations.

Also, a REST API user is consuming an API, whereas a CLI wrapper is consuming an API to implement another. Much bigger fish to fry there, I think.

[aeroxis]

You make a very good point. Sultan, at the end of the day, is a syntactic sugar for Subprocess. It has a couple of doo-dads for remote SSH execution, and things like that.

I originally wanted to have Sultan to do exactly what you're saying, but when I started diving into it, it seemed like a task that was very tough to solve. For example, grep's syntax remains similar between OS, but it has some API changes between versions. Trying to figure out what version has what syntax seems a bit daunting, and perhaps impossible to do with all commands.

The usecase that Sultan really caters to is the developer who writes their code on one OS, and keeps that code in the same OS across different environments. Not everyone wants their code to run across different OS and Distributions. I felt like it was a special case to do this, and decided to keep Sultan as generic as possible and let developers build the logic for different OS and Distributions on top of it.

The problem Sultan does solve is code maintainability, reusability within their own project (which assumes the project runs on 1 OS), and testability (unit and integration tests can be written, while you can't do that in Bash easily).