Replies: 2 comments 4 replies
-
|
Cool! Be sure to include our license alongside your own in the source, sdist, and wheel. |
Beta Was this translation helpful? Give feedback.
4 replies
-
|
Yeah, I'm not an expert at interpreting these, but thanks! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I love Click and usually reach for it when building a CLI. However, I'll occasionally use
argparsefor projects where I don't want to introduce another dependency. For example, projects where the CLI is ancillary to the main project (e.g. providing an interface viapython -m packagename). In these cases, I really miss the excellentCliRunnerprovided by Click for unit testing. To solve this, I've ported Click's CliRunner to a standalone project, clirunner, and modified it to work with "regular" CLIs built withargparseor manualsys.argvparsing.The interface is the same as Click's CliRunner minus any Click-specific things. Behavior is the same with two exceptions:
stderris flushed on exit so that you can testprint("Foo", file=sys.stderr)type statements. Click doesn't do this which changes the expected behavior asstderris normally line-buffered in the standard library. This is fine for Click apps usingecho()which does flush the buffer but for non-Click apps, this could result in unexpected behavior.stdoutandstderrproperties of theResultobject are always available andmix_stderroption is removed. This matches the desired behavior forCliRunner: restrictmix_stderrinfluence to<output>; keep<stderr>and<stdout>stable #2522 for which there is an open pull-request.clirunner.CliRunner should make it easier to test these "non-Click" projects while giving you an easy upgrade path if you do later to decide to use Click as the tests will be the same.
Beta Was this translation helpful? Give feedback.
All reactions