mitmproxy/examples/addons/commands-simple.py

"""Add a custom command to mitmproxy's command prompt."""
import logging

from mitmproxy import command


class MyAddon:
    def __init__(self):
        self.num = 0

    @command.command("myaddon.inc")
    def inc(self) -> None:
        self.num += 1
        logging.info(f"num = {self.num}")


addons = [MyAddon()]
restructure examples - restructure examples (fix #4031) - remove example dependencies from setup.py, we do not need special dependencies for our supported addons. - unify how we generate docs from code - improve example docs 2020-06-22 23:53:39 +00:00			`"""Add a custom command to mitmproxy's command prompt."""`
switch to stdlib logging mitmproxy previously used a homegrown logging mechanism based around `mitmproxy.ctx.log` and the `add_log` hook. This worked well for everything we control, but does not work outside the mitmproxy universe. For now we have simply ignored logging in e.g. tornado or h2, but with the upcoming introduction of mitmproxy_wireguard we now have a dependency on some Rust/PyO3 code for which we definitely want logs, but which also cannot easily be changed to use our homegrown logging (PyO3 does the heavy lifting to add interoperability with stdlib logging). Long story short, we want to introduce a log handler for stdlib logging. Now there are two ways how such a handler could operate: 1. We could build a handler that forwards all stdlib log events into our homegrown mechanism. 2. We embrace stdlib's logging as the correct way to do things, and get rid of our homegrown stuff. This PR follows the second approach by removing the `add_log` hook and rewriting the `TermLog` and `EventStore` addons to listen for stdlib log records. This means that all `mitmproxy.ctx.log.info` events are now simply `logging.info` etc. One upside of this approach is that many parts of the codebase now don't depend on the existence of `mitmproxy.ctx` and we can use off-the-shelf things like pytest's `caplog`. We can also now better colorize log output and/or add timestamps. 2022-09-17 13:41:54 +00:00			`import logging`

All new documentation This patch does a lot. - Ditch sphinx in favor of hugo. This gives us complete control of the layout and presentation of our docs. Henceforth, docs will be hosted on our website rather than ReadTheDocs. - Create a simple, clean doc layout and theme. - Remove large parts of the documentaion. I've ditched anything that was a) woefully out of date, b) too detailed, or c) too hard to maintain in the long term. - Huge updates to the docs themselves: completely rewrite addons documentation, add docs for core concepts like commands and options, and revise and tweak a lot of the existing docs. With this patch, we're also changing the way we publish and maintain the docs. From now on, we don't publish docs for every release. Instead, the website will contain ONE set of docs for each major release. The online docs will be updated if needed as minor releases are made. Docs are free to improve during minor releases, but anything that changes behaviour sufficiently to require a doc change warrants a new major release. This also leaves us free to progressively update and improve docs out of step with our release cadence. With this new scheme, I feel CI over the docs is less important. I've removed it for now, but won't object if someone wants to add it back in. 2018-02-22 04:21:34 +00:00			`from mitmproxy import command`


			`class MyAddon:`
			`def __init__(self):`
			`self.num = 0`

			`@command.command("myaddon.inc")`
			`def inc(self) -> None:`
			`self.num += 1`
switch to stdlib logging mitmproxy previously used a homegrown logging mechanism based around `mitmproxy.ctx.log` and the `add_log` hook. This worked well for everything we control, but does not work outside the mitmproxy universe. For now we have simply ignored logging in e.g. tornado or h2, but with the upcoming introduction of mitmproxy_wireguard we now have a dependency on some Rust/PyO3 code for which we definitely want logs, but which also cannot easily be changed to use our homegrown logging (PyO3 does the heavy lifting to add interoperability with stdlib logging). Long story short, we want to introduce a log handler for stdlib logging. Now there are two ways how such a handler could operate: 1. We could build a handler that forwards all stdlib log events into our homegrown mechanism. 2. We embrace stdlib's logging as the correct way to do things, and get rid of our homegrown stuff. This PR follows the second approach by removing the `add_log` hook and rewriting the `TermLog` and `EventStore` addons to listen for stdlib log records. This means that all `mitmproxy.ctx.log.info` events are now simply `logging.info` etc. One upside of this approach is that many parts of the codebase now don't depend on the existence of `mitmproxy.ctx` and we can use off-the-shelf things like pytest's `caplog`. We can also now better colorize log output and/or add timestamps. 2022-09-17 13:41:54 +00:00			`logging.info(f"num = {self.num}")`
All new documentation This patch does a lot. - Ditch sphinx in favor of hugo. This gives us complete control of the layout and presentation of our docs. Henceforth, docs will be hosted on our website rather than ReadTheDocs. - Create a simple, clean doc layout and theme. - Remove large parts of the documentaion. I've ditched anything that was a) woefully out of date, b) too detailed, or c) too hard to maintain in the long term. - Huge updates to the docs themselves: completely rewrite addons documentation, add docs for core concepts like commands and options, and revise and tweak a lot of the existing docs. With this patch, we're also changing the way we publish and maintain the docs. From now on, we don't publish docs for every release. Instead, the website will contain ONE set of docs for each major release. The online docs will be updated if needed as minor releases are made. Docs are free to improve during minor releases, but anything that changes behaviour sufficiently to require a doc change warrants a new major release. This also leaves us free to progressively update and improve docs out of step with our release cadence. With this new scheme, I feel CI over the docs is less important. I've removed it for now, but won't object if someone wants to add it back in. 2018-02-22 04:21:34 +00:00

make it black! 2022-04-26 11:53:35 +00:00			`addons = [MyAddon()]`