wdb.server.aiohttp


Namewdb.server.aiohttp JSON
Version 1.0.0 PyPI version JSON
download
home_pagehttps://github.com/shepilov-vladislav/wdb_server_aiohttp
SummaryAn improbable web debugger through WebSockets (server)
upload_time2020-11-26 13:08:45
maintainer
docs_urlNone
authorShepilov Vladislav
requires_python
licenseGPLv3
keywords
VCS
bugtrack_url
requirements No requirements were recorded.
Travis-CI No Travis.
coveralls test coverage No coveralls.
            # wdb[aiohttp] - Web Debugger
![Pylint Status](https://github.com/shepilov-vladislav/wdb_server_aiohttp/workflows/Pylint/badge.svg?branch=master)
![Flake8 Status](https://github.com/shepilov-vladislav/wdb_server_aiohttp/workflows/Flake8/badge.svg?branch=master)
![Pytest Status](https://github.com/shepilov-vladislav/wdb_server_aiohttp/workflows/Pytest/badge.svg?branch=master)

# About this project
This is not original `wdb.server`, original `wdb.server` placed [here](https://github.com/Kozea/wdb/tree/master/server)

# Why?
Original project was written more that 6 years ago, with `tornado` on backend and `coffescript/bower/grunt` on frontend.
These are very old technologies. I wanted to be able to expand functionality and fix bugs.
But I don't want to study and support the product based on old technologies.

# What's difference beetween original wdb.server and this project

- Tornado -> aiohttp
- Coffescript -> Typescript
- Bower -> npm
- Grunt -> Webpack
- yapf -> black
- Added support of themes for any screen
- Added responsibility for `PROCESSES` tab
- Added support of Safari
- wdb now works without internet access(original project required Google fonts from CDN)
- 100% Code coverage
- Used alpine base image

# What's plans?

- Change [CodeMirror](http://codemirror.net/) -> [Monaco](https://microsoft.github.io/monaco-editor)
- Cover frontend with unit tests
- Add integration tests frontend <-> backend
- Add support of multithread/multiprocess/async deebugging

# Description

[![](https://raw.github.com/Kozea/wdb/master/wdb.png)](https://raw.github.com/Kozea/wdb/master/wdb-lg.png)


**wdb** is a full featured web debugger based on a client-server architecture.

The wdb server which is responsible of managing debugging instances along with browser connections (through websockets) is based on [aiohttp](https://docs.aiohttp.org).
The wdb clients allow step by step debugging, in-program python code execution, code edition (based on [CodeMirror](http://codemirror.net/)) setting breakpoints...

Due to this architecture, all of this is fully compatible with **multithread** and **multiprocess** programs.

**wdb** works with python 2 (2.6, 2.7), python 3 (3.2, 3.3, 3.4, 3.5) and pypy.
Even better, it is possible to debug a python 2 program with a wdb server running on python 3 and vice-versa or debug a program running on a computer with a debugging server running on another computer inside a web page on a third computer!

Even betterer, it is now possible to pause a currently running python process/thread using code injection from the web interface. (This requires gdb and ptrace enabled)

In other words it's a very enhanced version of pdb directly in your browser with nice features.


## Installation:

Global installation:

```
    $ pip install wdb.server.aiohttp
```

In virtualenv or with a different python installation:

```
    $ pip install wdb
```

(You must have the server installed and running)

## Quick test

To try wdb, first you have to start the wdb server:

```
    $ wdb.server.py &
```

Next run:

```
    $ python -m wdb your_file.py
```

Wdb will open a debugging window right in your browser, paused at the beginning of your program.

You can access to <http://localhost:1984/> to have an overview of the server.

NB: You have to start the server only once. Multiple Debugging sessions can be run simultaneously without problem.

This is not the only way to debug a program, see below.


## Usage

### Setting trace

To debug any program, with the server on, just add:

```python
    import wdb
    wdb.set_trace()
```

anywhere in your code. Your program will stop at the set_trace line. (Just like pdb)


### Tracing code

To inspect your code on exception, you can do the following:

```python
    from wdb import trace
    with trace():
        wrong_code()
```

Any exception during `wrong_code` will launch a debugging session.

You can also use the `start_trace()` and `stop_trace` methods.
(It's better to put the `stop_trace` in a finally block to avoid tracing all your program after an exception.)


### Debugging web servers

wdb provides some tools to make it work nicely with different webservers:


#### Wsgi servers

For wsgi servers you can use the `WdbMiddleware`:

```python
    from wdb.ext import WdbMiddleware
    wsgi_app = Whathever_wsgi_server_lib()
    my_app = WdbMiddleware(wsgi_app)
    my_app.serve_forever()
```

##### Flask

or using Flask:

```python
    from flask import Flask
    from wdb.ext import WdbMiddleware
    app = Flask(__name__)
    app.debug = True
    app.wsgi_app = WdbMiddleware(app.wsgi_app)
    app.run(use_debugger=False) # Disable builtin Werkzeug debugger
```

you can also use the [Flask-Wdb](https://github.com/techniq/flask-wdb/) extension

```python
    from flask import Flask
    from flask_wdb import Wdb

    app = Flask(__name__)
    app.debug = True
    Wdb(app)

    app.run()
```

##### Django

or using django:

Add the middleware in your `wsgi.py`:

After:

```python
    from django.core.wsgi import get_wsgi_application
    application = get_wsgi_application()
```

Add this:

```python
    from wdb.ext import WdbMiddleware
    application = WdbMiddleware(application)
```

And in your `settings.py`, activate exception propagation:

```python
    DEBUG = True
    DEBUG_PROPAGATE_EXCEPTIONS = True
```

##### CherryPy

or using CherryPy:

```python
import cherrypy
from wdb.ext import WdbMiddleware

class HelloWorld(object):
    @cherrypy.expose
    def index(self):
        undefined_method() # This will fail
        return "Hello World!"

cherrypy.config.update({'global':{'request.throw_errors': True}})
app = cherrypy.Application(HelloWorld())
app.wsgiapp.pipeline.append(('debugger', WdbMiddleware))

cherrypy.quickstart(app)
```

#### Tornado

In tornado, which is not a wsgi server, you can use the `wdb_tornado` function which will monkey patch the execute method on RequestHandlers:

```python
    from wdb.ext import wdb_tornado
    from tornado.web import Application
    my_app = Application([(r"/", MainHandler)])
    if options.debug:
        wdb_tornado(my_app)
    my_app.listen(8888)
```

#### Page loading time become slow


If wdb slows down too much of your application (tracing all the things takes time), you can start it disabled with:

```python
    my_app = WdbMiddleware(wsgi_app, start_disabled=True)  # or
    wdb_tornado(my_app, start_disabled=True)
```

Then when you get an exception just click on the on/off button.


## Remote debugging

You can easily do remote debugging with wdb:

Let's say you want to run a program `p.py` on computer A and you want to debug it on computer B.

Start wdb server on computer A and launch this:

```
    WDB_NO_BROWSER_AUTO_OPEN=True python -m wdb p.py
```

And open a browser on computer B at the url given by wdb log.


Now you can also run wdb server on a computer C and run on computer A:

```
    WDB_NO_BROWSER_AUTO_OPEN=True WDB_SOCKET_SERVER=computerC.addr WDB_SOCKET_PORT=19840 python -m wdb p.py
```

And go with computer B to http://computerC/debug/session/[uuid in log] there you can step into p.py running in computer A. Yay !

You can use different configurations:

See `wdb.server.py --help` for changing ports on server and these environnement vars for wdb instances:

```
WDB_SOCKET_SERVER         # WDB server host
WDB_SOCKET_PORT           # WDB server socket port
WDB_WEB_SERVER            # WDB server host for browser openning
WDB_WEB_PORT              # WDB server http port
WDB_NO_BROWSER_AUTO_OPEN  # To disable the automagic browser openning (which can't be done if the browser is not on the same machine)
```
### Docker

If you are developing locally with [Docker](http://www.docker.com/), you can
also use wdb to debug a code running inside a container. The basic setup looks
like this:

1. Start `wdb.server.py ` running in a container and expose port `1984` to your
   host computer, this will server the debugging web server.
2. Start debugging in your app container, making sure to set `WDB_SOCKET_SERVER`
   to the address of the server container, and point it to the expoed port
   `19840` on that server.
3. When a trace is reached, open up `http://<your-docker-hostname>:1984`

I will walk through this process in detail, using
[Docker Compose](https://docs.docker.com/compose/) to set up the containers.

Let's say your `docker-compose.yml` looks like
[their example for using with Django](https://docs.docker.com/compose/django/):

```yaml
db:
  image: postgres
web:
  build: .
  command: python manage.py runserver 0.0.0.0:8000
  volumes:
    - .:/code
  ports:
    - "8000:8000"
  links:
    - db
```

Next lets add the wdb server part now and tell the web to link to it:

```yaml
db:
  image: postgres
web:
  build: .
  command: python manage.py runserver 0.0.0.0:8000
  volumes:
    - .:/code
  ports:
    - "8000:8000"
  links:
    - db
    - wdb
  environment:
    WDB_SOCKET_SERVER: wdb
    WDB_NO_BROWSER_AUTO_OPEN: True
wdb:
  image: shepilov-vladislav/wdb
  ports:
    - "1984:1984"
```

And add `wdb` to your `requirements.txt` in your web app:

```bash
$ echo 'wdb' >> requirements.txt
```

Now we can use `wdb.set_trace()` in our python app.

```python
# ... some code
import wdb
wdb.set_trace()
```
Then you have to rebuild your web application and start everything up again

```bash
$ docker-compose stop
$ docker-compose build web
$ docker-compose up
```


Now you can access `http://<local docker server>:1984`, to
see the traces as they come up in your app.

## In browser usage

Once you are in a breakpoint or in an exception, you can eval all you want in the prompt under the code.
Multi-lines are partially supported using `[Shift] + [Enter]`.
There is now help available by clicking on the top help button.

As of now the following special commands are supported during breakpoint:

    * .s or [Ctrl] + [↓] or [F11]    : Step into
    * .n or [Ctrl] + [→] or [F10]    : Step over (Next)
    * .r or [Ctrl] + [↑] or [F9]     : Step out (Return)
    * .c or [Ctrl] + [←] or [F8]     : Continue
    * .u or [F7]                     : Until (Next over loops)
    * .j lineno                      : Jump to lineno (Must be at bottom frame and in the same function)
    * .b arg                         : Set a session breakpoint, see below for what arg can be*
    * .t arg                         : Set a temporary breakpoint, arg follow the same syntax as .b
    * .z arg                         : Delete existing breakpoint
    * .l                             : List active breakpoints
    * .f                             : Echo all typed commands in the current debugging session
    * .d expression                  : Dump the result of expression in a table
    * .w expression                  : Watch expression in current file (Click on the name to remove)
    * .q                             : Quit
    * .h                             : Get some help
    * .e                             : Toggle file edition mode
    * .g                             : Clear prompt
    * .i [mime/type;]expression      : Display the result in an embed, mime type is auto detected on linux and defaults to "text/html" otherwise
    * iterable!sthg                  : If cutter is installed, executes cut(iterable).sthg
    * expr >! file                   : Write the result of expr in file
    * !< file                        : Eval the content of file
    * [Enter]                        : Eval the current selected text in page, useful to eval code in the source
    *
    * * arg is using the following syntax:
    *   [file/module][:lineno][#function][,condition]
    * which means:
    *   - [file]                    : Break if any line of `file` is executed
    *   - [file]:lineno             : Break on `file` at `lineno`
    *   - [file][:lineno],condition : Break on `file` at `lineno` if `condition` is True (ie: i == 10)
    *   - [file]#function           : Break when inside `function` function
    *
    * File is always current file by default and you can also specify a module like `logging.config`.

You can also eval a variable in the source by middle clicking on it.
You can add/remove a breakpoint by clicking on the line number.

NB: Hotkeys with arrows are purposely not triggered in the eval prompt to avoid conflicts when typing.


## Wdb Server

To see which debugging session are currently open, open your browser at <http://localhost:1984/>.
You can also close crashed session.

From there you should also see all python process and their threads running and you can try to pause them during their execution to do step by step debugging and current variable inspection. **This is highly experimental and requires gdb and a kernel with ptrace enabled to inject python code into a running python process.**
If you get `ptrace: Operation not permitted.` you will have to enable it.

Depending on your system it might work with:
```bash
echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
```

Make sure that wdb is installed for the python version running the program too.


## Importing wdb each time is exhausting

Yes to avoid that, you can add a `w` builtin at the beggining of your application:


```python
    from wdb.ext import add_w_builtin
    add_w_builtin()
```

you can now use the `w` object any where in your code:

```python
    my_code()
    w.tf  # Stop next line
    doubtful_code()
```


```python
    my_code()
    with w.trace():
        doubtful_code()
```

## Code completion

Wdb has dynamic code completion in eval prompt thanks to [jedi](https://github.com/davidhalter/jedi).


## FAQ

### In Firefox opened debugging pages are not closed when done

It's a firefox config flag, visit `about:config` and set:
`dom.allow_scripts_to_close_windows` to `true`

### The logs are spammed with 'parsing Python module'

If your logging configuration is set to display DEBUG logs, you may see a log for every imported file in your project any time WDB is active, like so:

```
DEBUG 2017-07-16 13:15:03,772 index 49835 123145573191680 parsing Python module /project/.virtualenv/python-3.6.1/lib/python3.6/site-packages/package/file.py for indexing
```


To silence only this message, add a config for the importmagic module. For example:

```
LOGGING = {
    ...
    'loggers': {
        ...
        'importmagic.index': {
            'level': 'ERROR',
            'propagate': False,
        },
    },
}
```


## Contribute

All contributions are more than welcomed, use the fork luke !


## Author

[Florian Mounier](http://github.com/paradoxxxzero) @ [Kozea](http://kozea.fr/)
[Shepilov Vladislav](https://github.com/shepilov-vladislav)


## Licence

This library is licensed under GPLv3
            

Raw data

            {
    "_id": null,
    "home_page": "https://github.com/shepilov-vladislav/wdb_server_aiohttp",
    "name": "wdb.server.aiohttp",
    "maintainer": "",
    "docs_url": null,
    "requires_python": "",
    "maintainer_email": "",
    "keywords": "",
    "author": "Shepilov Vladislav",
    "author_email": "shepilov.v@protonmail.com",
    "download_url": "https://files.pythonhosted.org/packages/25/54/cbc5e6fe5b2066e383f7fbc63940a1bc8f17d7e030b256149f377aba1803/wdb.server.aiohttp-1.0.0.tar.gz",
    "platform": "Any",
    "description": "# wdb[aiohttp] - Web Debugger\n![Pylint Status](https://github.com/shepilov-vladislav/wdb_server_aiohttp/workflows/Pylint/badge.svg?branch=master)\n![Flake8 Status](https://github.com/shepilov-vladislav/wdb_server_aiohttp/workflows/Flake8/badge.svg?branch=master)\n![Pytest Status](https://github.com/shepilov-vladislav/wdb_server_aiohttp/workflows/Pytest/badge.svg?branch=master)\n\n# About this project\nThis is not original `wdb.server`, original `wdb.server` placed [here](https://github.com/Kozea/wdb/tree/master/server)\n\n# Why?\nOriginal project was written more that 6 years ago, with `tornado` on backend and `coffescript/bower/grunt` on frontend.\nThese are very old technologies. I wanted to be able to expand functionality and fix bugs.\nBut I don't want to study and support the product based on old technologies.\n\n# What's difference beetween original wdb.server and this project\n\n- Tornado -> aiohttp\n- Coffescript -> Typescript\n- Bower -> npm\n- Grunt -> Webpack\n- yapf -> black\n- Added support of themes for any screen\n- Added responsibility for `PROCESSES` tab\n- Added support of Safari\n- wdb now works without internet access(original project required Google fonts from CDN)\n- 100% Code coverage\n- Used alpine base image\n\n# What's plans?\n\n- Change [CodeMirror](http://codemirror.net/) -> [Monaco](https://microsoft.github.io/monaco-editor)\n- Cover frontend with unit tests\n- Add integration tests frontend <-> backend\n- Add support of multithread/multiprocess/async deebugging\n\n# Description\n\n[![](https://raw.github.com/Kozea/wdb/master/wdb.png)](https://raw.github.com/Kozea/wdb/master/wdb-lg.png)\n\n\n**wdb** is a full featured web debugger based on a client-server architecture.\n\nThe wdb server which is responsible of managing debugging instances along with browser connections (through websockets) is based on [aiohttp](https://docs.aiohttp.org).\nThe wdb clients allow step by step debugging, in-program python code execution, code edition (based on [CodeMirror](http://codemirror.net/)) setting breakpoints...\n\nDue to this architecture, all of this is fully compatible with **multithread** and **multiprocess** programs.\n\n**wdb** works with python 2 (2.6, 2.7), python 3 (3.2, 3.3, 3.4, 3.5) and pypy.\nEven better, it is possible to debug a python 2 program with a wdb server running on python 3 and vice-versa or debug a program running on a computer with a debugging server running on another computer inside a web page on a third computer!\n\nEven betterer, it is now possible to pause a currently running python process/thread using code injection from the web interface. (This requires gdb and ptrace enabled)\n\nIn other words it's a very enhanced version of pdb directly in your browser with nice features.\n\n\n## Installation:\n\nGlobal installation:\n\n```\n    $ pip install wdb.server.aiohttp\n```\n\nIn virtualenv or with a different python installation:\n\n```\n    $ pip install wdb\n```\n\n(You must have the server installed and running)\n\n## Quick test\n\nTo try wdb, first you have to start the wdb server:\n\n```\n    $ wdb.server.py &\n```\n\nNext run:\n\n```\n    $ python -m wdb your_file.py\n```\n\nWdb will open a debugging window right in your browser, paused at the beginning of your program.\n\nYou can access to <http://localhost:1984/> to have an overview of the server.\n\nNB: You have to start the server only once. Multiple Debugging sessions can be run simultaneously without problem.\n\nThis is not the only way to debug a program, see below.\n\n\n## Usage\n\n### Setting trace\n\nTo debug any program, with the server on, just add:\n\n```python\n    import wdb\n    wdb.set_trace()\n```\n\nanywhere in your code. Your program will stop at the set_trace line. (Just like pdb)\n\n\n### Tracing code\n\nTo inspect your code on exception, you can do the following:\n\n```python\n    from wdb import trace\n    with trace():\n        wrong_code()\n```\n\nAny exception during `wrong_code` will launch a debugging session.\n\nYou can also use the `start_trace()` and `stop_trace` methods.\n(It's better to put the `stop_trace` in a finally block to avoid tracing all your program after an exception.)\n\n\n### Debugging web servers\n\nwdb provides some tools to make it work nicely with different webservers:\n\n\n#### Wsgi servers\n\nFor wsgi servers you can use the `WdbMiddleware`:\n\n```python\n    from wdb.ext import WdbMiddleware\n    wsgi_app = Whathever_wsgi_server_lib()\n    my_app = WdbMiddleware(wsgi_app)\n    my_app.serve_forever()\n```\n\n##### Flask\n\nor using Flask:\n\n```python\n    from flask import Flask\n    from wdb.ext import WdbMiddleware\n    app = Flask(__name__)\n    app.debug = True\n    app.wsgi_app = WdbMiddleware(app.wsgi_app)\n    app.run(use_debugger=False) # Disable builtin Werkzeug debugger\n```\n\nyou can also use the [Flask-Wdb](https://github.com/techniq/flask-wdb/) extension\n\n```python\n    from flask import Flask\n    from flask_wdb import Wdb\n\n    app = Flask(__name__)\n    app.debug = True\n    Wdb(app)\n\n    app.run()\n```\n\n##### Django\n\nor using django:\n\nAdd the middleware in your `wsgi.py`:\n\nAfter:\n\n```python\n    from django.core.wsgi import get_wsgi_application\n    application = get_wsgi_application()\n```\n\nAdd this:\n\n```python\n    from wdb.ext import WdbMiddleware\n    application = WdbMiddleware(application)\n```\n\nAnd in your `settings.py`, activate exception propagation:\n\n```python\n    DEBUG = True\n    DEBUG_PROPAGATE_EXCEPTIONS = True\n```\n\n##### CherryPy\n\nor using CherryPy:\n\n```python\nimport cherrypy\nfrom wdb.ext import WdbMiddleware\n\nclass HelloWorld(object):\n    @cherrypy.expose\n    def index(self):\n        undefined_method() # This will fail\n        return \"Hello World!\"\n\ncherrypy.config.update({'global':{'request.throw_errors': True}})\napp = cherrypy.Application(HelloWorld())\napp.wsgiapp.pipeline.append(('debugger', WdbMiddleware))\n\ncherrypy.quickstart(app)\n```\n\n#### Tornado\n\nIn tornado, which is not a wsgi server, you can use the `wdb_tornado` function which will monkey patch the execute method on RequestHandlers:\n\n```python\n    from wdb.ext import wdb_tornado\n    from tornado.web import Application\n    my_app = Application([(r\"/\", MainHandler)])\n    if options.debug:\n        wdb_tornado(my_app)\n    my_app.listen(8888)\n```\n\n#### Page loading time become slow\n\n\nIf wdb slows down too much of your application (tracing all the things takes time), you can start it disabled with:\n\n```python\n    my_app = WdbMiddleware(wsgi_app, start_disabled=True)  # or\n    wdb_tornado(my_app, start_disabled=True)\n```\n\nThen when you get an exception just click on the on/off button.\n\n\n## Remote debugging\n\nYou can easily do remote debugging with wdb:\n\nLet's say you want to run a program `p.py` on computer A and you want to debug it on computer B.\n\nStart wdb server on computer A and launch this:\n\n```\n    WDB_NO_BROWSER_AUTO_OPEN=True python -m wdb p.py\n```\n\nAnd open a browser on computer B at the url given by wdb log.\n\n\nNow you can also run wdb server on a computer C and run on computer A:\n\n```\n    WDB_NO_BROWSER_AUTO_OPEN=True WDB_SOCKET_SERVER=computerC.addr WDB_SOCKET_PORT=19840 python -m wdb p.py\n```\n\nAnd go with computer B to http://computerC/debug/session/[uuid in log] there you can step into p.py running in computer A. Yay !\n\nYou can use different configurations:\n\nSee `wdb.server.py --help` for changing ports on server and these environnement vars for wdb instances:\n\n```\nWDB_SOCKET_SERVER         # WDB server host\nWDB_SOCKET_PORT           # WDB server socket port\nWDB_WEB_SERVER            # WDB server host for browser openning\nWDB_WEB_PORT              # WDB server http port\nWDB_NO_BROWSER_AUTO_OPEN  # To disable the automagic browser openning (which can't be done if the browser is not on the same machine)\n```\n### Docker\n\nIf you are developing locally with [Docker](http://www.docker.com/), you can\nalso use wdb to debug a code running inside a container. The basic setup looks\nlike this:\n\n1. Start `wdb.server.py ` running in a container and expose port `1984` to your\n   host computer, this will server the debugging web server.\n2. Start debugging in your app container, making sure to set `WDB_SOCKET_SERVER`\n   to the address of the server container, and point it to the expoed port\n   `19840` on that server.\n3. When a trace is reached, open up `http://<your-docker-hostname>:1984`\n\nI will walk through this process in detail, using\n[Docker Compose](https://docs.docker.com/compose/) to set up the containers.\n\nLet's say your `docker-compose.yml` looks like\n[their example for using with Django](https://docs.docker.com/compose/django/):\n\n```yaml\ndb:\n  image: postgres\nweb:\n  build: .\n  command: python manage.py runserver 0.0.0.0:8000\n  volumes:\n    - .:/code\n  ports:\n    - \"8000:8000\"\n  links:\n    - db\n```\n\nNext lets add the wdb server part now and tell the web to link to it:\n\n```yaml\ndb:\n  image: postgres\nweb:\n  build: .\n  command: python manage.py runserver 0.0.0.0:8000\n  volumes:\n    - .:/code\n  ports:\n    - \"8000:8000\"\n  links:\n    - db\n    - wdb\n  environment:\n    WDB_SOCKET_SERVER: wdb\n    WDB_NO_BROWSER_AUTO_OPEN: True\nwdb:\n  image: shepilov-vladislav/wdb\n  ports:\n    - \"1984:1984\"\n```\n\nAnd add `wdb` to your `requirements.txt` in your web app:\n\n```bash\n$ echo 'wdb' >> requirements.txt\n```\n\nNow we can use `wdb.set_trace()` in our python app.\n\n```python\n# ... some code\nimport wdb\nwdb.set_trace()\n```\nThen you have to rebuild your web application and start everything up again\n\n```bash\n$ docker-compose stop\n$ docker-compose build web\n$ docker-compose up\n```\n\n\nNow you can access `http://<local docker server>:1984`, to\nsee the traces as they come up in your app.\n\n## In browser usage\n\nOnce you are in a breakpoint or in an exception, you can eval all you want in the prompt under the code.\nMulti-lines are partially supported using `[Shift] + [Enter]`.\nThere is now help available by clicking on the top help button.\n\nAs of now the following special commands are supported during breakpoint:\n\n    * .s or [Ctrl] + [\u2193] or [F11]    : Step into\n    * .n or [Ctrl] + [\u2192] or [F10]    : Step over (Next)\n    * .r or [Ctrl] + [\u2191] or [F9]     : Step out (Return)\n    * .c or [Ctrl] + [\u2190] or [F8]     : Continue\n    * .u or [F7]                     : Until (Next over loops)\n    * .j lineno                      : Jump to lineno (Must be at bottom frame and in the same function)\n    * .b arg                         : Set a session breakpoint, see below for what arg can be*\n    * .t arg                         : Set a temporary breakpoint, arg follow the same syntax as .b\n    * .z arg                         : Delete existing breakpoint\n    * .l                             : List active breakpoints\n    * .f                             : Echo all typed commands in the current debugging session\n    * .d expression                  : Dump the result of expression in a table\n    * .w expression                  : Watch expression in current file (Click on the name to remove)\n    * .q                             : Quit\n    * .h                             : Get some help\n    * .e                             : Toggle file edition mode\n    * .g                             : Clear prompt\n    * .i [mime/type;]expression      : Display the result in an embed, mime type is auto detected on linux and defaults to \"text/html\" otherwise\n    * iterable!sthg                  : If cutter is installed, executes cut(iterable).sthg\n    * expr >! file                   : Write the result of expr in file\n    * !< file                        : Eval the content of file\n    * [Enter]                        : Eval the current selected text in page, useful to eval code in the source\n    *\n    * * arg is using the following syntax:\n    *   [file/module][:lineno][#function][,condition]\n    * which means:\n    *   - [file]                    : Break if any line of `file` is executed\n    *   - [file]:lineno             : Break on `file` at `lineno`\n    *   - [file][:lineno],condition : Break on `file` at `lineno` if `condition` is True (ie: i == 10)\n    *   - [file]#function           : Break when inside `function` function\n    *\n    * File is always current file by default and you can also specify a module like `logging.config`.\n\nYou can also eval a variable in the source by middle clicking on it.\nYou can add/remove a breakpoint by clicking on the line number.\n\nNB: Hotkeys with arrows are purposely not triggered in the eval prompt to avoid conflicts when typing.\n\n\n## Wdb Server\n\nTo see which debugging session are currently open, open your browser at <http://localhost:1984/>.\nYou can also close crashed session.\n\nFrom there you should also see all python process and their threads running and you can try to pause them during their execution to do step by step debugging and current variable inspection. **This is highly experimental and requires gdb and a kernel with ptrace enabled to inject python code into a running python process.**\nIf you get `ptrace: Operation not permitted.` you will have to enable it.\n\nDepending on your system it might work with:\n```bash\necho 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope\n```\n\nMake sure that wdb is installed for the python version running the program too.\n\n\n## Importing wdb each time is exhausting\n\nYes to avoid that, you can add a `w` builtin at the beggining of your application:\n\n\n```python\n    from wdb.ext import add_w_builtin\n    add_w_builtin()\n```\n\nyou can now use the `w` object any where in your code:\n\n```python\n    my_code()\n    w.tf  # Stop next line\n    doubtful_code()\n```\n\n\n```python\n    my_code()\n    with w.trace():\n        doubtful_code()\n```\n\n## Code completion\n\nWdb has dynamic code completion in eval prompt thanks to [jedi](https://github.com/davidhalter/jedi).\n\n\n## FAQ\n\n### In Firefox opened debugging pages are not closed when done\n\nIt's a firefox config flag, visit `about:config` and set:\n`dom.allow_scripts_to_close_windows` to `true`\n\n### The logs are spammed with 'parsing Python module'\n\nIf your logging configuration is set to display DEBUG logs, you may see a log for every imported file in your project any time WDB is active, like so:\n\n```\nDEBUG 2017-07-16 13:15:03,772 index 49835 123145573191680 parsing Python module /project/.virtualenv/python-3.6.1/lib/python3.6/site-packages/package/file.py for indexing\n```\n\n\nTo silence only this message, add a config for the importmagic module. For example:\n\n```\nLOGGING = {\n    ...\n    'loggers': {\n        ...\n        'importmagic.index': {\n            'level': 'ERROR',\n            'propagate': False,\n        },\n    },\n}\n```\n\n\n## Contribute\n\nAll contributions are more than welcomed, use the fork luke !\n\n\n## Author\n\n[Florian Mounier](http://github.com/paradoxxxzero) @ [Kozea](http://kozea.fr/)\n[Shepilov Vladislav](https://github.com/shepilov-vladislav)\n\n\n## Licence\n\nThis library is licensed under GPLv3",
    "bugtrack_url": null,
    "license": "GPLv3",
    "summary": "An improbable web debugger through WebSockets (server)",
    "version": "1.0.0",
    "split_keywords": [],
    "urls": [
        {
            "comment_text": "",
            "digests": {
                "md5": "76e38a7147a9c7dfd8ff5ba7f7c23c31",
                "sha256": "169cfce7a75682dd5daa4a2d39bdd9472a4756f6d1a6c8cca6e07f8c44ed9fd5"
            },
            "downloads": -1,
            "filename": "wdb.server.aiohttp-1.0.0.tar.gz",
            "has_sig": false,
            "md5_digest": "76e38a7147a9c7dfd8ff5ba7f7c23c31",
            "packagetype": "sdist",
            "python_version": "source",
            "requires_python": null,
            "size": 9458647,
            "upload_time": "2020-11-26T13:08:45",
            "upload_time_iso_8601": "2020-11-26T13:08:45.917121Z",
            "url": "https://files.pythonhosted.org/packages/25/54/cbc5e6fe5b2066e383f7fbc63940a1bc8f17d7e030b256149f377aba1803/wdb.server.aiohttp-1.0.0.tar.gz",
            "yanked": false,
            "yanked_reason": null
        }
    ],
    "upload_time": "2020-11-26 13:08:45",
    "github": true,
    "gitlab": false,
    "bitbucket": false,
    "github_user": null,
    "github_project": "shepilov-vladislav",
    "error": "Could not fetch GitHub repository",
    "lcname": "wdb.server.aiohttp"
}
        
Elapsed time: 0.19171s