sh 2.0.0 requests

[Andrew]

I'd like to aggregate some requests for 2.0.0 here. This is a great time to include breaking changes, since we have no obligation to support backwards compatibility with 1.*

The list so far, checkmarks next to the things that are done:

• Drop support for Python < 3.6
• Use tox for all tests, drop custom test harness code #526
• If running synchronously, only return a string, otherwise RunningCommand (tangentially related to #518)
• Support asyncio and allow commands to be awaited
• Change process model #495
• Better _tee support #215
• Migrate docs to readthedocs and version them (1.* and 2.*)
• Type annotations (#581)
• Remove b_cd support and encourage pushd (#584 (comment))

I will keep this issue open for awhile for feedback, and then organize issues and attach them to a milestone. @ecederstrand

[jerkstorecaller]

I don't have technical requests, but I would suggest that you think of the little people and keep sh's simple to use (as it is now) by people who aren't Python developers. If complex stuff like asyncio or anything else is optional, that's fine, but I don't want to learn advanced Python concepts. Of course, it's your library and you're free to do what you want.

Also please don't unpublish 1.x releases from pip. I don't know how pip works or if you have a storage limit, but someone I know ran into an issue last year where the dev went "aha, Python 2 out of support, I'm unpublishing it". It would suck if someone stuck on Python 3.4 can't install an older compatible release like 1.14, even 5 years from now.

[Mazlum Ağar]

Thanks for this awesome package. I like it.

Do you have a roadmap to support asyncio? When do you plan release version 2?

[Andrew]

@mazlum I have made more progress (this weekend in fact) on 2.0.0. Roadmapping with open source projects is challenging given their nature of fitting into the free time of the contributors. Completing 2.0.0 it this year is probably a guarantee.

[Mazlum Ağar]

@amoffat Thanks for your effort. I really like your package and I look forward to use with asyncio. Thanks again.

[Brian Ealdwine]

@amoffat not a request, but if you're looking at useful libs, wurlitzer might be handy.

[Brian Ealdwine]

request: venv activation support

as in
vsh = sh(_venv='foo/bar/bin/activate')

I thought this would work with:

environ = sh.bash('-c', '. foo/bar/bin/activate && env')
environ = <parse into dict>
vsh = sh(_env=environ)

..but that still gets 'CommandNotFound` unless the command is also present in the external environment (in which case I'm not sure which one it gets, but I think it gets the venv one -- however, that's fairly immeterial).

[Erik Cederstrand]

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 virtualenv bin folder to os.environ["PATH"] or sys.path. Or point sh to a specific python executable: python = sh.Command("foo/bar/bin/python3").