Show HN: Sultan – Pythonic interface to your shell(sultan.readthedocs.io) |
Show HN: Sultan – Pythonic interface to your shell(sultan.readthedocs.io) |
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.
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).
Invoke: http://www.pyinvoke.org/ wraps subprocess commands into Makefile-like tasks
Fabric: http://www.fabfile.org/ Same as invoke, but catered to remote subprocess commands over SSH
+1 for https://sultan.readthedocs.io/en/latest/sultan-examples.html...
I think it would be interesting if you could iterate on the results of "ls -l", where each row is represented by an object.
s(command_from_potentially_unsafe_source).run()
compare with os.system(command_from_potentially_unsafe_source)
or subprocess.call(command_from_potentially_unsafe_source, shell=True)
securitywise? I'm assuming all three are equally bad?Anyone know how the name came about?
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 :-)
Which was super useful for controlling some utilities that wanted to be run in an interactive bash shell.
This project looks interesting too, will give it a try.
BTW: Has anyone news on Fabric 2 ?
https://news.ycombinator.com/item?id=8735892#8737512
Edit: That comment was part of an HN thead about this topic, which might be interesting in its own right:
Streem – a new programming language from Matz (github.com)
(I know why not to use plumbum)
What do you know?
This line triggered me.
Nice stuff though
Fabric is great for DevOps, but there are applications that we build that aren't catered for DevOps work, and that is why I created Sultan.
https://docs.python.org/3/library/subprocess.html#using-the-...
"Xonsh is " NOT " how to do this."
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.