Erik Cederstrand

I opened a PR to showcase how lazy resolving could work: https://github.com/amoffat/sh/pull/616 With this PR you can do something like: ```python >>> from sh import python3 >>> python3("-c" "import sys;...

I have a feeling we're special-casing something that could be solved with standard Python customization patterns. With a small patch to `sh` you could do: ```python import json import sh...

@supriyo-biswas I just committed the above patch. Would my suggested solution work for you?

With the second PR, the standard case without the `sh.Command()` indirection also works: ```python import json from sh import RunningCommand, Command, echo class MyRunningCommand(RunningCommand): def json(self): return json.loads(str(self)) Command.RunningCommandCls =...

Nope, this will work just like before in the normal case. But if you want the output transformed to JSON, you call the `.json()` method.

Coming from C# and Java, I'm not sure I would call the 7 chars in `.json()` "boilerplate", compared to the alternative `_callable=...`. Anyway, if you really want to avoid the...

@amoffat I understand your concern and agree that messing with global state is problematic. It is actually possible to change the `RunningCommandCls` of just the execution context: ```python import sh...

Thanks for the detailed report! The docs you linked to state that: > These calls are only made if control is expected to return to the Python interpreter. However, that's...

I'm not sure I see the value of special virtualenv support. The `activate` command is just a fancy way of setting `PATH="$VIRTUAL_ENV/bin:$PATH"` so you should be able to prepend the...

That would have to wait for removal of Python 2 support. We're tracking various improvements suggested for a 2.0 release in https://github.com/amoffat/sh/issues/552, among them dropping support for Python 2.