Merge branch 'master' into release

.github/workflows/tests.yml

@@ -40,7 +40,7 @@ jobs:
     runs-on: macos-latest
     strategy:
       matrix:
-        python-version: [3.7, 3.8]
+        python-version: [3.7, 3.8, 3.9]
 
     steps:
     - uses: actions/checkout@v2
@@ -67,7 +67,7 @@ jobs:
     runs-on: windows-latest
     strategy:
       matrix:
-        python-version: [3.7, 3.8]
+        python-version: [3.7, 3.8, 3.9]
 
     steps:
     - uses: actions/checkout@v2

CHANGES.md

@@ -1,6 +1,20 @@
 Emmett changelog
 ================
 
+Version 2.2
+-----------
+
+Released on March 11th 2021, codename Copernicus
+
+- Slightly refactored request flow
+- Added `App.command_group` decorator
+- Added additional arguments acceptance in `AppModule`
+- Added static paths customisation for `AppModule`
+- Added `workers` options to `serve` command
+- Changed default logging level to `info` in `serve` command
+- Changed default `SameSite` policy for session cookies to `Lax`
+- Added official Python 3.9 support
+
 Version 2.1
 -----------
 

docs/app_and_modules.md

@@ -20,8 +20,12 @@ The signature of this class's `__init__` method looks like this:
 
 ```python
 def __init__(
-    self, import_name, root_path=None, url_prefix=None,
-    template_folder='templates', config_folder='config'
+    self,
+    import_name: str,
+    root_path: Optional[str] = None,
+    url_prefix: Optional[str] = None,
+    template_folder: str = 'templates',
+    config_folder: str = 'config'
 ):
     # internal code
 ```
@@ -36,17 +40,12 @@ Let's see the full parameters list in detail:
 | template_folder | allows you to set a different folder for your application's templates (by default Emmett uses the *templates* folder |
 | config_folder | allows you to set a different configuration folder for your application, if you wish to load your configuration from files |
 
-Since we introduced the `config_folder` parameter, let's see some details
-about application configuration.
+Since we introduced the `config_folder` parameter, let's see some details about application configuration.
 
 ### Application's configuration
 
-The `App` object provides a `config` attribute to let you configure your
-application easily. The `config` object is something like a Python dictionary,
-with a friendly syntax and the characteristic of *sub-namespace auto-creation*.   
-What does that mean? That you likely want to have the configuration
-divided into *categories*, separating the database configuration values
-from the particulars of your authorization layer or an extension. 
+The `App` object provides a `config` attribute to let you configure your application easily. The `config` object is something like a Python dictionary, with a friendly syntax and the characteristic of *sub-namespace auto-creation*.   
+What does that mean? That you likely want to have the configuration divided into *categories*, separating the database configuration values from the particulars of your authorization layer or an extension. 
 You can simply write:
 
 ```python
@@ -62,8 +61,7 @@ app.config.Haml.set_as_default = True
 
 without creating dictionaries for `db` or `Haml` directly.
 
-You can also load configuration from external files like *yaml*, 
-so let's see an example. With this application structure:
+You can also load configuration from external files like *yaml*, so let's see an example. With this application structure:
 
 ```
 /app.py
@@ -94,15 +92,12 @@ app.config_from_yaml('app.yml')
 app.config_from_yaml('db.yml', 'db')
 ```
 
-and your configuration will be loaded. As you can see, 
-when calling `config_from_yaml()`, you can pass the name
-of the namespace under which Emmett should load the configuration.
-
+and your configuration will be loaded. As you can see, when calling `config_from_yaml()`, you can pass the name of the namespace under which Emmett should load the configuration.
 
 Application modules
 -------------------
 
-*Changed in 1.0*
+*Changed in version 2.2*
 
 When your app's structure starts to come together, you might benefit of packing routes together in common structures, so you can use the same route prefix or hostname, or to have a common pipeline.
 
@@ -138,6 +133,8 @@ A part from the prefix, you can use several parameters when creating modules. He
 | name | name for the module, will be used by Emmett as the namespace for internal routing |
 | template_folder | allows you to set a specific sub-folder of your application template path for module templates |
 | template_path | allows you to set a specific folder inside your module root path for module templates |
+| static_folder | allows you to set a specific sub-folder of your application static path for module assets |
+| static_path | allows you to set a specific folder inside your module root path for module assets |
 | url_prefix | allows you to set a prefix path for module URLs |
 | hostname | allows you to set a specific hostname for module |
 | root_path | same as we seen for the `App` object |

docs/cli.md

@@ -54,3 +54,26 @@ The command will then be available on the command line:
 ```bash
 > emmett setup
 ```
+
+### Command groups
+
+*New in version 2.2*
+
+You might also want to define several commands within the same *logical group*. In this scenario, the `command_group` decorator is what you're looking for:
+
+```python
+@app.command_group('tasks')
+def tasks_cmd():
+    pass
+
+
+@tasks_cmd.command('create')
+def tasks_create_cmd():
+    # some code here
+```
+
+As you can see we defined a `tasks` command group, and a nested `create` command. We can invoke the upper command using:
+
+    > emmett tasks create
+
+In case you need more information, please check the [click documentation](https://click.palletsprojects.com/en/7.x/commands/) about commands and groups.

docs/deployment.md

@@ -8,6 +8,8 @@ If you want to use an ASGI server not listed in this section, please refer to it
 Included server
 ---------------
 
+*Changed in version 2.2*
+
 Emmett comes with an included server based on [uvicorn](https://www.uvicorn.org/). In order to run your application in production you can just use the included `serve` command:
 
     emmett serve --host 0.0.0.0 --port 80
@@ -18,10 +20,11 @@ You can inspect all the available options of the `serve` command using the `--he
 | --- | --- | --- |
 | host | 0.0.0.0 | Bind address |
 | port | 8000 | Bind port |
+| workers | 1 | Number of worker processes | 
 | loop | auto | Loop implementation (possible values: auto,asyncio,uvloop) |
 | http-protocol | auto | HTTP protocol implementation (possible values: auto,h11,httptools) |
 | ws-protocol | auto | Websocket protocol implementation (possible values: auto,websockets,wsproto) |
-| log-level | warning | Logging level (possible values: debug,info,warning,error,critical) |
+| log-level | info | Logging level (possible values: debug,info,warning,error,critical) |
 | access-log | (flag) enabled | Enable/disable access log |
 | proxy-headers | (flag) disabled | Enable/disable proxy headers |
 | proxy-trust-ips | | Comma separated list of IPs to trust for proxy headers |
@@ -52,7 +55,7 @@ Even if Docker is not properly a deployment option, we think giving an example o
 In order to keep the image lighter, we suggest to use the *slim* Python image as a source:
 
 ```Dockerfile
-FROM python:3.8-slim
+FROM python:3.9-slim
 
 RUN mkdir -p /usr/src/deps
 COPY requirements.txt /usr/src/deps