[FEATURE] Add a __main__.py to schemathesis.cli

[mardukbp]

Is your feature request related to a problem? Please describe

In some enterprise environments there is a list of allowed executables. In such an environment the easiest (and sometimes the only) way to use schemathesis is by executing the schemathesis.cli module with python -m. However, this is currently not possible, because this module does not have a __main__.py file.

Describe the solution you'd like

A __main__.py file in the module schemathesis.cli with the following contents:

import schemathesis
 
if __name__ == '__main__':
    schemathesis.cli.schemathesis()

Describe alternatives you've considered

I tried using the runner, but the request body and the response body are base64-encoded and I want so see them. Currently, the only option is to use the CLI to generate a cassette.

Additional context

[Stranger6667]

Is there anything that prevents decoding base64 in your circumstances? I.e. if the value is nested too deep, etc.

I want so see them.

Where do you look at them? Is it your console, or some logs?

[mardukbp]

AFAIK if the content-type is application/json, the body is always a string and it should stay untouched. Why is it base64-encoded?

Anyway, this feature request is independent from that. st.exe cannot be executed in enterprise environments with a list of allowed exes.

[Stranger6667]

AFAIK if the content-type is application/json, the body is always a string and it should stay untouched. Why is it base64-encoded?

Even though I'd appreciate answers to my original questions about the troubles with decoding base64 to better understand your use case and, therefore, give a more informed answer, there are a couple of reasons for using base64:

• The events can carry any response body bytes, not only of the application/json content type, hence they are unified to support any content type
• Some servers lie about application/json, and send e.g. non-UTF-8 / non-JSON data, or add BOM, etc. Interpreting such responses as text leads to either replacing invalid bytes or erroring. Both of these options do not help with debugging as some potentially useful information is lost.

Therefore, preserving the original bytes as they are is reasonable. The runner events, of course, can use bytes and serialize to base64 on demand, but it will require some complications and will break consumers who may still expect that events can be serialized to JSON with the standard json module (this contract wasn't documented explicitly but only discussed a few times). In the next major version I want to rework the serialization format and it may change.

Support for python -m schemathesis.cli will come in the next release.

[mardukbp]

Thank you very much for your thorough explanation. Now I understand why the response body is base64-encoded. Of course I can decode it myself, but it requires some extra work.

I noticed that with cassette files base64-encoding is opt-in, but with the runner there is no opt-out. That bothered me. I think opt-in provides more flexibility, but it requires that the user is aware of the caveats you mentioned. Maybe you should add that info to the documentation.

Support for python -m schemathesis.cli will come in the next release.

Awesome! Thank you very much.

[Stranger6667]

Thank you for your response! Maybe it could be some extra helper to decode the body + docs on this