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
-
I love Click and usually reach for it when building a CLI. However, I'll occasionally use
argparse
for 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 excellentCliRunner
provided 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 withargparse
or manualsys.argv
parsing.The interface is the same as Click's CliRunner minus any Click-specific things. Behavior is the same with two exceptions:
stderr
is flushed on exit so that you can testprint("Foo", file=sys.stderr)
type statements. Click doesn't do this which changes the expected behavior asstderr
is 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.stdout
andstderr
properties of theResult
object are always available andmix_stderr
option is removed. This matches the desired behavior forCliRunner
: restrictmix_stderr
influence 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