sh 2.0.0 requests

[amoffat]

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:

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

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]

Thanks for this awesome package. I like it.

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

[amoffat]

@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]

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

[eode]

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

[eode]

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).

[ecederstrand]

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").