I like PBS (now sh.py) for certain use cases. If I'm writing an actual shell script, I think it is brilliant. It keeps the script focused on the task at hand instead of Python's somewhat painful process communication.
On the other hand, if I have an application that needs to communicate with a subprocess as a small piece of the whole, I'll use other methods that are less "magical". It's not that I'm inherently against magic, but rather that, in that use case, I generally want very explicit control over what is happening.
This tool hijacks the import mechanism by directly writing to Python's look-up tables. After all, when you do
from sh import git
there's no module 'sh' invoked in the normal sense. Instead, the library generates a wrapper for the shell command 'git' on the fly. While that kind of monkey patching may be neat, it's also a bit brittle and a potential security issue.
Python has a lot of built-in support for overriding how imports work, and modules have always been just namespaces. As hacks go, this isn't very hacky in Python, and it isn't particularly brittle, as it's just implementing existing interfaces.
It is also not "monkeypatching", which ought to be reserved for things that involve reaching into an existing class and modifying things. This on-demand loading, which doesn't have anywhere near the same evil factor, but is rather more like dynamic programming languages working-as-designed.
You may find this distasteful. I do, actually, though I'm not 100% sure why. But it's not because it's some sort of abuse of Python. Python is very nearly designed to do this, and the last little bit that it isn't designed for isn't that big a deal, especially compared to something like the "import python modules through zipfiles" functionality, which now ships with the core.
It's true that it is another place that you can get a python script to execute code outside of its environment, but you get a ton of those for free with the stdlib.
Well, the Python and Ruby communities have different engineering cultures and this is part of that. "Explicit is better than implicit" is one of the mantras on the Python side.
You expect import imports names which have actually been declared somewhere. Names which you can find and look at the definition. This library essentially hijacks the import process to allow you to import any name, each name is then actually a wrapper on a system to run shell commands. Definitely a hack, but a cool and useful looking hack.
That is a reasonable assumption in the common case, but it's reasonable to not always assume that. The same is true if you have obj.v(), you would normally expect there to be some v property defined on the object but really it might be coming dynamically from __getattr__().
This is something that python specifically has language level support for, I wouldn't say it's a hack just because its using a feature that isn't taught in Python 101.
Rightly or wrongly I expect import to be simple, fail only when packages haven't been installed properly, and more generally depend only on PYTHONPATH. When I'm debugging I don't normally even look at the import statements. Other replies have described what this does; I think I'd rather offer such functionality as something that looks like a method call that might fail (something like git = sh.getProxyForShellCommand("git") - probably not that verbose, my head's in java-land at the moment, but you get the idea)
On the other hand, if I have an application that needs to communicate with a subprocess as a small piece of the whole, I'll use other methods that are less "magical". It's not that I'm inherently against magic, but rather that, in that use case, I generally want very explicit control over what is happening.