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.
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.
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).
This seems to be a simple wrapper around subprocess, but I'm afraid it is not changing things dramatically. Overall, I don't agree that Sultan's syntax is any more Pythonic than subprocess itself.
Representing each row as an object works, but it ends up having us write custom objects for different result types. When you run Sultan().ls('-l'), you will get back a list of Strings, which you can freely use in Python for your specific needs (like use a Regex to fetch date/times or file size). I felt like this offers developers the best flexibility, rather than trying to customize each output (which will definitely make the codebase very confusing)
While PS-native stuff yield objects, not all pre-PS utilities/builtins are overriden or have interface for PS and output old fashioned text blob, which is not automagically parsed in any way by PS. My comment was system-level, not utility-level.
I hadn't actually noticed that! It looks like .run() allows input and output to be piped and the return code captured. That is a serious improvement over subprocess.call().
It looks like it allows stdin, stdout, stderr and return code to be handled properly which call() doesn't. It's still syntactic sugar over Popen() and communicate() but will cut down boilerplate for calling external processes.
There is also pyinfra [1], which provides the same sort of features for both local and remote devices, yet designed for consistent deployments and state diffing.
When I dabble with Python to get a job done, I invariably end up using subprocess at some stage and going through some contortions. I like the look of Sultan, it seems well thought out and has loads of well written docs.
Since I was creating a tool that works with Commands, I thought of the tag line "Command and Rule Your Shell", and I thought of different types of rulers (Kings, Shahs, Czars, Sultans, etc.). The Sultan name seemed to fit the best.
I was also trying to grow a Handlebar mustache at the time, and I wanted my logo to have a Handlebar Mustache, so that's why the logo has a Handlebar Mustache :-)
I've been using 'tentakel' for remote server admin for years, 'fabric' for lightweight deployment, and more recently 'invoke' for local invocations (all are Python projects).
This project looks interesting too, will give it a try.
Ive written numerous python wrappers around shell commands for all sorts of one off utils, but this is nice and flexible and generic. Sultan looks well thought out. Open to contributors?
Sultan is open for contribution. Feel free to put your thoughts in the Issues for features you'd like, and submit any Pull Requests for any issues that already exist.
Seems like there is lots of talk here about how this is thin wrapper over `subprocess`, but I like the idea. What I don't like is that the logo looks like a penis with a mustache.
Yes it is. I looked at SH before writing Sultan. I was not very crazy about the syntax. I wanted the code to be easy to read, because one of my primary goals was the code maintainability, and that requires the code to be as readable as possible.
OK. I thought this would be so obvious that people would see it. Sultan says "Sultan was created to help with scripts that we create with Bash, that tend to get complex." If one has an open mind, one should be asking "why would I use bash for this at all, when there exists a far superior command shell, xonsh, which incorporates all of bash's capability, with all of python, in one piece?"
Why are we trying to interface with bash to run commands from python in the first place? Cut out the middleman, bash, which is just a nuisance in the way.
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.