lambda-api-decorators-cdk 0.2.3__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- lambda_api_decorators_cdk-0.2.3/.github/workflows/release.yml +85 -0
- lambda_api_decorators_cdk-0.2.3/.gitignore +9 -0
- lambda_api_decorators_cdk-0.2.3/AGENTS.md +232 -0
- lambda_api_decorators_cdk-0.2.3/LICENSE +21 -0
- lambda_api_decorators_cdk-0.2.3/PKG-INFO +144 -0
- lambda_api_decorators_cdk-0.2.3/README.md +98 -0
- lambda_api_decorators_cdk-0.2.3/pyproject.toml +104 -0
- lambda_api_decorators_cdk-0.2.3/setup.cfg +4 -0
- lambda_api_decorators_cdk-0.2.3/src/lambda_api_decorators_cdk/__init__.py +5 -0
- lambda_api_decorators_cdk-0.2.3/src/lambda_api_decorators_cdk/api_type.py +8 -0
- lambda_api_decorators_cdk-0.2.3/src/lambda_api_decorators_cdk/ast_helper.py +361 -0
- lambda_api_decorators_cdk-0.2.3/src/lambda_api_decorators_cdk/lambda_api.py +85 -0
- lambda_api_decorators_cdk-0.2.3/src/lambda_api_decorators_cdk/lambda_api_config.py +151 -0
- lambda_api_decorators_cdk-0.2.3/src/lambda_api_decorators_cdk/resource_builder.py +794 -0
- lambda_api_decorators_cdk-0.2.3/src/lambda_api_decorators_cdk/source_layout.py +8 -0
- lambda_api_decorators_cdk-0.2.3/src/lambda_api_decorators_cdk.egg-info/PKG-INFO +144 -0
- lambda_api_decorators_cdk-0.2.3/src/lambda_api_decorators_cdk.egg-info/SOURCES.txt +37 -0
- lambda_api_decorators_cdk-0.2.3/src/lambda_api_decorators_cdk.egg-info/dependency_links.txt +1 -0
- lambda_api_decorators_cdk-0.2.3/src/lambda_api_decorators_cdk.egg-info/requires.txt +1 -0
- lambda_api_decorators_cdk-0.2.3/src/lambda_api_decorators_cdk.egg-info/scm_file_list.json +34 -0
- lambda_api_decorators_cdk-0.2.3/src/lambda_api_decorators_cdk.egg-info/scm_version.json +8 -0
- lambda_api_decorators_cdk-0.2.3/src/lambda_api_decorators_cdk.egg-info/top_level.txt +1 -0
- lambda_api_decorators_cdk-0.2.3/tests/conftest.py +50 -0
- lambda_api_decorators_cdk-0.2.3/tests/test_ast_decorator_invocations.py +247 -0
- lambda_api_decorators_cdk-0.2.3/tests/test_ast_helper.py +133 -0
- lambda_api_decorators_cdk-0.2.3/tests/test_http_builder.py +54 -0
- lambda_api_decorators_cdk-0.2.3/tests/test_lambda_api.py +311 -0
- lambda_api_decorators_cdk-0.2.3/tests/test_lambda_api_config.py +221 -0
- lambda_api_decorators_cdk-0.2.3/tests/test_lambda_function.py +91 -0
- lambda_api_decorators_cdk-0.2.3/tests/test_layer_autodiscovery.py +496 -0
- lambda_api_decorators_cdk-0.2.3/tests/test_packaging_current.py +12 -0
- lambda_api_decorators_cdk-0.2.3/tests/test_permission_resolution.py +504 -0
- lambda_api_decorators_cdk-0.2.3/tests/test_public_api.py +49 -0
- lambda_api_decorators_cdk-0.2.3/tests/test_resource_builder_options.py +88 -0
- lambda_api_decorators_cdk-0.2.3/tests/test_resource_builder_state.py +105 -0
- lambda_api_decorators_cdk-0.2.3/tests/test_resource_graph.py +61 -0
- lambda_api_decorators_cdk-0.2.3/tests/test_resource_registries.py +267 -0
- lambda_api_decorators_cdk-0.2.3/tests/test_rest_builder.py +55 -0
- lambda_api_decorators_cdk-0.2.3/tests/test_source_layout.py +173 -0
|
@@ -0,0 +1,85 @@
|
|
|
1
|
+
name: Release to PyPI
|
|
2
|
+
|
|
3
|
+
on:
|
|
4
|
+
push:
|
|
5
|
+
tags:
|
|
6
|
+
- "v*"
|
|
7
|
+
|
|
8
|
+
permissions:
|
|
9
|
+
contents: read
|
|
10
|
+
|
|
11
|
+
jobs:
|
|
12
|
+
release:
|
|
13
|
+
runs-on: ubuntu-latest
|
|
14
|
+
environment: pypi
|
|
15
|
+
permissions:
|
|
16
|
+
contents: read
|
|
17
|
+
id-token: write
|
|
18
|
+
|
|
19
|
+
steps:
|
|
20
|
+
- name: Check out tagged revision
|
|
21
|
+
uses: actions/checkout@v4
|
|
22
|
+
with:
|
|
23
|
+
fetch-depth: 0
|
|
24
|
+
|
|
25
|
+
- name: Set up Python
|
|
26
|
+
uses: actions/setup-python@v5
|
|
27
|
+
with:
|
|
28
|
+
python-version: "3.12"
|
|
29
|
+
|
|
30
|
+
- name: Validate release tag
|
|
31
|
+
env:
|
|
32
|
+
RELEASE_TAG: ${{ github.ref_name }}
|
|
33
|
+
run: |
|
|
34
|
+
if [[ ! "$RELEASE_TAG" =~ ^v[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
|
|
35
|
+
echo "Invalid release tag: $RELEASE_TAG" >&2
|
|
36
|
+
exit 1
|
|
37
|
+
fi
|
|
38
|
+
|
|
39
|
+
- name: Install test and build dependencies
|
|
40
|
+
run: |
|
|
41
|
+
python -m pip install --upgrade pip
|
|
42
|
+
python -m pip install build pytest setuptools-scm
|
|
43
|
+
python -m pip install .
|
|
44
|
+
|
|
45
|
+
- name: Run tests
|
|
46
|
+
run: pytest -q
|
|
47
|
+
|
|
48
|
+
- name: Build distributions
|
|
49
|
+
run: python -m build
|
|
50
|
+
|
|
51
|
+
- name: Verify generated package version
|
|
52
|
+
env:
|
|
53
|
+
RELEASE_TAG: ${{ github.ref_name }}
|
|
54
|
+
run: |
|
|
55
|
+
generated_version="$(python -m setuptools_scm)"
|
|
56
|
+
expected_version="${RELEASE_TAG#v}"
|
|
57
|
+
echo "Tag version: $expected_version"
|
|
58
|
+
echo "Generated version: $generated_version"
|
|
59
|
+
if [[ "$generated_version" != "$expected_version" ]]; then
|
|
60
|
+
echo "Generated package version does not match the release tag" >&2
|
|
61
|
+
exit 1
|
|
62
|
+
fi
|
|
63
|
+
python - "$expected_version" <<'PY'
|
|
64
|
+
from email.parser import BytesParser
|
|
65
|
+
from pathlib import Path
|
|
66
|
+
from zipfile import ZipFile
|
|
67
|
+
import sys
|
|
68
|
+
|
|
69
|
+
expected_version = sys.argv[1]
|
|
70
|
+
wheel = next(Path("dist").glob("*.whl"))
|
|
71
|
+
with ZipFile(wheel) as archive:
|
|
72
|
+
metadata_path = next(
|
|
73
|
+
name for name in archive.namelist()
|
|
74
|
+
if name.endswith(".dist-info/METADATA")
|
|
75
|
+
)
|
|
76
|
+
metadata = BytesParser().parsebytes(archive.read(metadata_path))
|
|
77
|
+
if metadata["Version"] != expected_version:
|
|
78
|
+
raise SystemExit(
|
|
79
|
+
f"Wheel version {metadata['Version']} does not match {expected_version}"
|
|
80
|
+
)
|
|
81
|
+
print(f"Wheel metadata version: {metadata['Version']}")
|
|
82
|
+
PY
|
|
83
|
+
|
|
84
|
+
- name: Publish distributions to PyPI
|
|
85
|
+
uses: pypa/gh-action-pypi-publish@release/v1
|
|
@@ -0,0 +1,232 @@
|
|
|
1
|
+
# Lambda API Decorators CDK — Agent Instructions
|
|
2
|
+
|
|
3
|
+
## Project purpose
|
|
4
|
+
|
|
5
|
+
This repository contains **Lambda API Decorators CDK**, the AWS CDK integration for the Lambda API Decorators project.
|
|
6
|
+
|
|
7
|
+
The project goal is:
|
|
8
|
+
|
|
9
|
+
> Define AWS Lambda APIs with Python decorators and automatically generate the infrastructure with AWS CDK.
|
|
10
|
+
|
|
11
|
+
GitHub organization:
|
|
12
|
+
|
|
13
|
+
`lambda-api-decorators`
|
|
14
|
+
|
|
15
|
+
Package:
|
|
16
|
+
|
|
17
|
+
`lambda-api-decorators-cdk`
|
|
18
|
+
|
|
19
|
+
Python module:
|
|
20
|
+
|
|
21
|
+
`lambda_api_decorators_cdk`
|
|
22
|
+
|
|
23
|
+
Project documentation:
|
|
24
|
+
|
|
25
|
+
`https://lambda-api-decorators.github.io/`
|
|
26
|
+
|
|
27
|
+
## Design principles
|
|
28
|
+
|
|
29
|
+
Follow these principles when changing the project:
|
|
30
|
+
|
|
31
|
+
> Simple by default, CDK-native when needed.
|
|
32
|
+
|
|
33
|
+
> Convention when convenient, configuration when needed.
|
|
34
|
+
|
|
35
|
+
> Explicit configuration always wins over convention.
|
|
36
|
+
|
|
37
|
+
Prefer small, composable APIs over large constructors or abstractions.
|
|
38
|
+
|
|
39
|
+
Do not add configuration knobs before the corresponding feature has been designed.
|
|
40
|
+
|
|
41
|
+
Do not introduce compatibility shims or aliases unless explicitly requested.
|
|
42
|
+
|
|
43
|
+
## Public architecture
|
|
44
|
+
|
|
45
|
+
The intended architecture is:
|
|
46
|
+
|
|
47
|
+
```text
|
|
48
|
+
LambdaApi
|
|
49
|
+
↓
|
|
50
|
+
LambdaApiConfig
|
|
51
|
+
↓
|
|
52
|
+
ResourceBuilder
|
|
53
|
+
↓
|
|
54
|
+
AWS CDK
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
`LambdaApi` is the recommended high-level CDK construct.
|
|
58
|
+
|
|
59
|
+
`LambdaApiConfig` contains reusable Lambda/API build configuration and creates isolated `ResourceBuilder` snapshots.
|
|
60
|
+
|
|
61
|
+
`ResourceBuilder` remains the lower-level engine and a supported public API.
|
|
62
|
+
|
|
63
|
+
Do not duplicate `ResourceBuilder` option-resolution or precedence logic in higher-level classes.
|
|
64
|
+
|
|
65
|
+
## Configuration lifecycle
|
|
66
|
+
|
|
67
|
+
The high-level lifecycle is:
|
|
68
|
+
|
|
69
|
+
```text
|
|
70
|
+
configure
|
|
71
|
+
↓
|
|
72
|
+
construct
|
|
73
|
+
↓
|
|
74
|
+
build
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
Configuration intended to affect generated Lambda resources must exist before `LambdaApi` construction.
|
|
78
|
+
|
|
79
|
+
Do not expose post-build configuration APIs that imply already-created resources can be retroactively changed.
|
|
80
|
+
|
|
81
|
+
## Mutable state
|
|
82
|
+
|
|
83
|
+
Avoid mutable default arguments.
|
|
84
|
+
|
|
85
|
+
Reusable configuration must not share mutable container state across builds.
|
|
86
|
+
|
|
87
|
+
Shallow-copy configuration containers when isolation is required.
|
|
88
|
+
|
|
89
|
+
Do not deep-copy AWS CDK constructs.
|
|
90
|
+
|
|
91
|
+
CDK objects supplied by callers should normally preserve object identity.
|
|
92
|
+
|
|
93
|
+
## AWS CDK usage
|
|
94
|
+
|
|
95
|
+
Prefer AWS CDK interfaces in public type annotations when the actual implementation supports them.
|
|
96
|
+
|
|
97
|
+
Do not claim support for an interface unless the underlying implementation can actually operate on all supported instances.
|
|
98
|
+
|
|
99
|
+
Be careful with JSII Python proxy identity.
|
|
100
|
+
|
|
101
|
+
Two accesses to the same CDK property may produce different Python proxy objects.
|
|
102
|
+
|
|
103
|
+
When appropriate, compare stable CDK properties instead of Python proxy identity.
|
|
104
|
+
|
|
105
|
+
## REST and HTTP APIs
|
|
106
|
+
|
|
107
|
+
REST is the semantic default for `LambdaApi`.
|
|
108
|
+
|
|
109
|
+
Standard created and imported REST APIs are supported by the current high-level API.
|
|
110
|
+
|
|
111
|
+
Concrete `apigatewayv2.HttpApi` instances are supported.
|
|
112
|
+
|
|
113
|
+
Do not claim general imported `IHttpApi` support unless route construction is explicitly redesigned to support it.
|
|
114
|
+
|
|
115
|
+
## Backward compatibility
|
|
116
|
+
|
|
117
|
+
Existing `ResourceBuilder` behavior is compatibility-sensitive.
|
|
118
|
+
|
|
119
|
+
Before modifying `ResourceBuilder`, determine whether the change affects existing direct callers.
|
|
120
|
+
|
|
121
|
+
Do not silently change existing low-level behavior to simplify a new high-level API.
|
|
122
|
+
|
|
123
|
+
When a new behavior conflicts with legacy behavior, prefer an explicit compatibility boundary.
|
|
124
|
+
|
|
125
|
+
## Scope discipline
|
|
126
|
+
|
|
127
|
+
Implement only the feature requested by the current task.
|
|
128
|
+
|
|
129
|
+
Do not opportunistically implement future roadmap items.
|
|
130
|
+
|
|
131
|
+
In particular, do not mix unrelated changes involving:
|
|
132
|
+
|
|
133
|
+
* source packaging;
|
|
134
|
+
* layer discovery;
|
|
135
|
+
* permissions;
|
|
136
|
+
* resource registries;
|
|
137
|
+
* Lambda identity or caching;
|
|
138
|
+
* logical-ID redesign;
|
|
139
|
+
* decorator syntax;
|
|
140
|
+
* supported HTTP methods;
|
|
141
|
+
* API Gateway security features.
|
|
142
|
+
|
|
143
|
+
A task may explicitly authorize one or more of these areas.
|
|
144
|
+
|
|
145
|
+
## Testing workflow
|
|
146
|
+
|
|
147
|
+
Tests are part of the public contract.
|
|
148
|
+
|
|
149
|
+
Do not weaken, delete, skip, or mark tests `xfail` simply to make a change pass.
|
|
150
|
+
|
|
151
|
+
When a task starts from a red test baseline, preserve the intended assertions while implementing the feature.
|
|
152
|
+
|
|
153
|
+
Equivalent parametrization is acceptable, but do not silently remove behavioral coverage.
|
|
154
|
+
|
|
155
|
+
Use real AWS CDK constructs when JSII runtime behavior, construct ownership, or type inference matters.
|
|
156
|
+
|
|
157
|
+
Mock or monkeypatch narrow boundaries when necessary to avoid Docker or Lambda bundling.
|
|
158
|
+
|
|
159
|
+
## Required verification
|
|
160
|
+
|
|
161
|
+
After code changes, run at minimum:
|
|
162
|
+
|
|
163
|
+
```bash
|
|
164
|
+
pytest -q
|
|
165
|
+
python -m compileall -q src tests
|
|
166
|
+
git diff --check
|
|
167
|
+
git status --short
|
|
168
|
+
```
|
|
169
|
+
|
|
170
|
+
When test inventory matters, also run:
|
|
171
|
+
|
|
172
|
+
```bash
|
|
173
|
+
pytest --collect-only -q
|
|
174
|
+
```
|
|
175
|
+
|
|
176
|
+
The existing test suite must remain green unless the current task explicitly establishes a deliberate red baseline.
|
|
177
|
+
|
|
178
|
+
## Docker and bundling
|
|
179
|
+
|
|
180
|
+
Unit tests should not require Docker unless the task explicitly concerns bundling behavior that cannot otherwise be tested.
|
|
181
|
+
|
|
182
|
+
Prefer testing packaging-path calculation and construct orchestration independently from Docker-based bundling.
|
|
183
|
+
|
|
184
|
+
## Git workflow
|
|
185
|
+
|
|
186
|
+
Do not push changes to a remote repository unless explicitly requested.
|
|
187
|
+
|
|
188
|
+
Do not create or update pull requests unless explicitly requested.
|
|
189
|
+
|
|
190
|
+
Do not create unrelated branches.
|
|
191
|
+
|
|
192
|
+
Do not amend or rewrite existing commits unless explicitly requested.
|
|
193
|
+
|
|
194
|
+
If the task explicitly says PLAN ONLY, AUDIT ONLY, REVIEW ONLY, or TESTS ONLY, respect that boundary exactly.
|
|
195
|
+
|
|
196
|
+
## Planning and audits
|
|
197
|
+
|
|
198
|
+
For architectural changes, inspect the existing implementation before proposing a design.
|
|
199
|
+
|
|
200
|
+
Identify:
|
|
201
|
+
|
|
202
|
+
* current behavior;
|
|
203
|
+
* public compatibility constraints;
|
|
204
|
+
* affected files;
|
|
205
|
+
* tests that protect current behavior;
|
|
206
|
+
* proposed API;
|
|
207
|
+
* migration or compatibility boundary;
|
|
208
|
+
* deferred work.
|
|
209
|
+
|
|
210
|
+
Do not implement during a PLAN ONLY or AUDIT ONLY task.
|
|
211
|
+
|
|
212
|
+
## Documentation
|
|
213
|
+
|
|
214
|
+
The repository README should explain this package clearly and link prominently to the complete project documentation.
|
|
215
|
+
|
|
216
|
+
Central documentation is the source for complete cross-package architecture and guides.
|
|
217
|
+
|
|
218
|
+
Avoid duplicating large documentation sections across repositories.
|
|
219
|
+
|
|
220
|
+
## General engineering guidance
|
|
221
|
+
|
|
222
|
+
Prefer straightforward code over clever abstractions.
|
|
223
|
+
|
|
224
|
+
Avoid speculative generalization.
|
|
225
|
+
|
|
226
|
+
Preserve type clarity.
|
|
227
|
+
|
|
228
|
+
Keep public APIs intentionally small.
|
|
229
|
+
|
|
230
|
+
When an implementation detail is not useful to callers, keep it private.
|
|
231
|
+
|
|
232
|
+
If repository behavior contradicts an assumption in the task, report the conflict rather than silently redesigning unrelated code.
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2024 Lambda API Decorators CDK
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
|
@@ -0,0 +1,144 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: lambda-api-decorators-cdk
|
|
3
|
+
Version: 0.2.3
|
|
4
|
+
Summary: AWS CDK integration for Lambda API Decorators. Generate AWS Lambda and API Gateway infrastructure from decorated Python handlers.
|
|
5
|
+
Author: Mateo Marcos, Emanuel Arguinarena, Lucas Picchi
|
|
6
|
+
License: MIT License
|
|
7
|
+
|
|
8
|
+
Copyright (c) 2024 Lambda API Decorators CDK
|
|
9
|
+
|
|
10
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
11
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
12
|
+
in the Software without restriction, including without limitation the rights
|
|
13
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
14
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
15
|
+
furnished to do so, subject to the following conditions:
|
|
16
|
+
|
|
17
|
+
The above copyright notice and this permission notice shall be included in all
|
|
18
|
+
copies or substantial portions of the Software.
|
|
19
|
+
|
|
20
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
21
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
22
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
23
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
24
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
25
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
26
|
+
SOFTWARE.
|
|
27
|
+
Project-URL: Homepage, https://github.com/lambda-api-decorators/lambda-api-decorators-cdk
|
|
28
|
+
Project-URL: Repository, https://github.com/lambda-api-decorators/lambda-api-decorators-cdk
|
|
29
|
+
Project-URL: Bug Reports, https://github.com/lambda-api-decorators/lambda-api-decorators-cdk
|
|
30
|
+
Keywords: cdk,lambda,aws,api gateway,ast
|
|
31
|
+
Classifier: Development Status :: 2 - Pre-Alpha
|
|
32
|
+
Classifier: Intended Audience :: Developers
|
|
33
|
+
Classifier: Framework :: AWS CDK :: 2
|
|
34
|
+
Classifier: Topic :: Software Development :: Libraries :: Python Modules
|
|
35
|
+
Classifier: Topic :: Software Development :: Build Tools
|
|
36
|
+
Classifier: License :: OSI Approved :: MIT License
|
|
37
|
+
Classifier: Programming Language :: Python :: 3.9
|
|
38
|
+
Classifier: Programming Language :: Python :: 3.10
|
|
39
|
+
Classifier: Programming Language :: Python :: 3.11
|
|
40
|
+
Classifier: Programming Language :: Python :: 3.12
|
|
41
|
+
Requires-Python: >=3.9
|
|
42
|
+
Description-Content-Type: text/markdown
|
|
43
|
+
License-File: LICENSE
|
|
44
|
+
Requires-Dist: aws-cdk.aws-lambda-python-alpha
|
|
45
|
+
Dynamic: license-file
|
|
46
|
+
|
|
47
|
+
# Lambda API Decorators CDK
|
|
48
|
+
|
|
49
|
+
## A library for AWS API Gateway/Lambda Proxy Integration
|
|
50
|
+
|
|
51
|
+
Lambda API Decorators CDK allows simplified resource creation for AWS Lambda functions and Rest API resources by using decorators and setting a builder with default, common or custom values for IAM Roles, Runtimes, Timeouts, Layers, Environment values, etc. This project relies abstract syntactic trees (ast) to analyze the code of your lambda functions and generate infraestructure accordingly.
|
|
52
|
+
|
|
53
|
+
### Installation
|
|
54
|
+
|
|
55
|
+
`lambda_api_decorators_cdk` is available from PyPI as `lambda-api-decorators-cdk`:
|
|
56
|
+
|
|
57
|
+
pip install lambda-api-decorators-cdk
|
|
58
|
+
|
|
59
|
+
Installation of [lambda-api-decorators](https://pypi.org/project/lambda-api-decorators/) is also required as a dependency for your lambda functions, since it provides the definition of decorators used within this module.
|
|
60
|
+
|
|
61
|
+
|
|
62
|
+
### Example
|
|
63
|
+
|
|
64
|
+
```python
|
|
65
|
+
import lambda_api_decorators_cdk
|
|
66
|
+
or
|
|
67
|
+
from lambda_api_decorators_cdk import ResourceBuilder
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
### Builder instance
|
|
71
|
+
|
|
72
|
+
You may define a builder using lambda_api_decorators_cdk's constructor `ResourceBuilder`. This method returns an instance of the class that will be used to configure and create your Lambda Functions. By default, no parameters are required to instantiate the object, but custom options may be passed in advanced use cases.
|
|
73
|
+
|
|
74
|
+
```python
|
|
75
|
+
from lambda_api_decorators_cdk import ResourceBuilder
|
|
76
|
+
|
|
77
|
+
builder = ResourceBuilder()
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
### Builder Configuration
|
|
81
|
+
|
|
82
|
+
If opted to, you can set default values for IAM Roles, Memory Size, Timeout, Runtime and VPC.
|
|
83
|
+
|
|
84
|
+
On the same note, support for common configuration that all the Lambda Functions will receive, such as Security Groups, Environment variables and Layers, is provided.
|
|
85
|
+
|
|
86
|
+
Lastly you can setup custom environments, layers, security groups, vpcs a Lambda Function will receive ONLY if they have the decorators defined.
|
|
87
|
+
|
|
88
|
+
```python
|
|
89
|
+
from lambda_api_decorators_cdk import ResourceBuilder
|
|
90
|
+
from aws_cdk import Duration
|
|
91
|
+
|
|
92
|
+
builder = ResourceBuilder()
|
|
93
|
+
builder.set_default_timeout(Duration.seconds(30))
|
|
94
|
+
builder.add_common_environment("DATABASE_URI", "something-db-related")
|
|
95
|
+
builder.add_custom_environment("URL-PREFIX", "lambda-api-decorators-cdk-") #Lambda Function should have decorator @environment("URL-PREFIX")
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
### Building
|
|
99
|
+
|
|
100
|
+
Assuming you have already instantiated a Builder, configured it and ready to deploy your stack, then simply define the directory of your Lambda Functions and build!
|
|
101
|
+
|
|
102
|
+
Note: For a Lambda Function to be recognised and built, it has to have a decorator specifying the HTTP method it responds to. Decorators are defined in the [lambda-api-decorators](https://pypi.org/project/lambda-api-decorators/) package.
|
|
103
|
+
|
|
104
|
+
```python
|
|
105
|
+
[...] # Imports
|
|
106
|
+
|
|
107
|
+
class LambdaApiDecoratorsExampleStack(Stack):
|
|
108
|
+
|
|
109
|
+
def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
|
|
110
|
+
super().__init__(scope, construct_id, **kwargs)
|
|
111
|
+
|
|
112
|
+
[...] # Instantiating builder, defining options and layers...
|
|
113
|
+
|
|
114
|
+
lambda_path = 'lambdas'
|
|
115
|
+
|
|
116
|
+
restapi = apigateway.RestApi(
|
|
117
|
+
self, 'lambda-api-decorators-RestApi',
|
|
118
|
+
rest_api_name= 'lambda-api-decorators-restApi')
|
|
119
|
+
root_resource = restapi.root
|
|
120
|
+
|
|
121
|
+
builder.build(self, root_resource, lambda_path, print_tree=True)
|
|
122
|
+
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
## Maintainer releases
|
|
126
|
+
|
|
127
|
+
The Git tag is the single source of truth for this package's version. For
|
|
128
|
+
example, `v0.3.0` produces Python package version `0.3.0`. This repository is
|
|
129
|
+
versioned independently from `lambda-api-decorators`.
|
|
130
|
+
|
|
131
|
+
To release from `main`, choose and push a semantic version tag:
|
|
132
|
+
|
|
133
|
+
```bash
|
|
134
|
+
git checkout main
|
|
135
|
+
git pull
|
|
136
|
+
|
|
137
|
+
git tag v0.3.0
|
|
138
|
+
git push origin v0.3.0
|
|
139
|
+
```
|
|
140
|
+
|
|
141
|
+
Pushing the tag triggers the release workflow, which tests, builds, verifies
|
|
142
|
+
the version, and publishes with PyPI trusted publishing. The PyPI project must
|
|
143
|
+
have a trusted publisher configured for this repository, the `release.yml`
|
|
144
|
+
workflow, and the `pypi` GitHub environment.
|
|
@@ -0,0 +1,98 @@
|
|
|
1
|
+
# Lambda API Decorators CDK
|
|
2
|
+
|
|
3
|
+
## A library for AWS API Gateway/Lambda Proxy Integration
|
|
4
|
+
|
|
5
|
+
Lambda API Decorators CDK allows simplified resource creation for AWS Lambda functions and Rest API resources by using decorators and setting a builder with default, common or custom values for IAM Roles, Runtimes, Timeouts, Layers, Environment values, etc. This project relies abstract syntactic trees (ast) to analyze the code of your lambda functions and generate infraestructure accordingly.
|
|
6
|
+
|
|
7
|
+
### Installation
|
|
8
|
+
|
|
9
|
+
`lambda_api_decorators_cdk` is available from PyPI as `lambda-api-decorators-cdk`:
|
|
10
|
+
|
|
11
|
+
pip install lambda-api-decorators-cdk
|
|
12
|
+
|
|
13
|
+
Installation of [lambda-api-decorators](https://pypi.org/project/lambda-api-decorators/) is also required as a dependency for your lambda functions, since it provides the definition of decorators used within this module.
|
|
14
|
+
|
|
15
|
+
|
|
16
|
+
### Example
|
|
17
|
+
|
|
18
|
+
```python
|
|
19
|
+
import lambda_api_decorators_cdk
|
|
20
|
+
or
|
|
21
|
+
from lambda_api_decorators_cdk import ResourceBuilder
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
### Builder instance
|
|
25
|
+
|
|
26
|
+
You may define a builder using lambda_api_decorators_cdk's constructor `ResourceBuilder`. This method returns an instance of the class that will be used to configure and create your Lambda Functions. By default, no parameters are required to instantiate the object, but custom options may be passed in advanced use cases.
|
|
27
|
+
|
|
28
|
+
```python
|
|
29
|
+
from lambda_api_decorators_cdk import ResourceBuilder
|
|
30
|
+
|
|
31
|
+
builder = ResourceBuilder()
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
### Builder Configuration
|
|
35
|
+
|
|
36
|
+
If opted to, you can set default values for IAM Roles, Memory Size, Timeout, Runtime and VPC.
|
|
37
|
+
|
|
38
|
+
On the same note, support for common configuration that all the Lambda Functions will receive, such as Security Groups, Environment variables and Layers, is provided.
|
|
39
|
+
|
|
40
|
+
Lastly you can setup custom environments, layers, security groups, vpcs a Lambda Function will receive ONLY if they have the decorators defined.
|
|
41
|
+
|
|
42
|
+
```python
|
|
43
|
+
from lambda_api_decorators_cdk import ResourceBuilder
|
|
44
|
+
from aws_cdk import Duration
|
|
45
|
+
|
|
46
|
+
builder = ResourceBuilder()
|
|
47
|
+
builder.set_default_timeout(Duration.seconds(30))
|
|
48
|
+
builder.add_common_environment("DATABASE_URI", "something-db-related")
|
|
49
|
+
builder.add_custom_environment("URL-PREFIX", "lambda-api-decorators-cdk-") #Lambda Function should have decorator @environment("URL-PREFIX")
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
### Building
|
|
53
|
+
|
|
54
|
+
Assuming you have already instantiated a Builder, configured it and ready to deploy your stack, then simply define the directory of your Lambda Functions and build!
|
|
55
|
+
|
|
56
|
+
Note: For a Lambda Function to be recognised and built, it has to have a decorator specifying the HTTP method it responds to. Decorators are defined in the [lambda-api-decorators](https://pypi.org/project/lambda-api-decorators/) package.
|
|
57
|
+
|
|
58
|
+
```python
|
|
59
|
+
[...] # Imports
|
|
60
|
+
|
|
61
|
+
class LambdaApiDecoratorsExampleStack(Stack):
|
|
62
|
+
|
|
63
|
+
def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
|
|
64
|
+
super().__init__(scope, construct_id, **kwargs)
|
|
65
|
+
|
|
66
|
+
[...] # Instantiating builder, defining options and layers...
|
|
67
|
+
|
|
68
|
+
lambda_path = 'lambdas'
|
|
69
|
+
|
|
70
|
+
restapi = apigateway.RestApi(
|
|
71
|
+
self, 'lambda-api-decorators-RestApi',
|
|
72
|
+
rest_api_name= 'lambda-api-decorators-restApi')
|
|
73
|
+
root_resource = restapi.root
|
|
74
|
+
|
|
75
|
+
builder.build(self, root_resource, lambda_path, print_tree=True)
|
|
76
|
+
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
## Maintainer releases
|
|
80
|
+
|
|
81
|
+
The Git tag is the single source of truth for this package's version. For
|
|
82
|
+
example, `v0.3.0` produces Python package version `0.3.0`. This repository is
|
|
83
|
+
versioned independently from `lambda-api-decorators`.
|
|
84
|
+
|
|
85
|
+
To release from `main`, choose and push a semantic version tag:
|
|
86
|
+
|
|
87
|
+
```bash
|
|
88
|
+
git checkout main
|
|
89
|
+
git pull
|
|
90
|
+
|
|
91
|
+
git tag v0.3.0
|
|
92
|
+
git push origin v0.3.0
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
Pushing the tag triggers the release workflow, which tests, builds, verifies
|
|
96
|
+
the version, and publishes with PyPI trusted publishing. The PyPI project must
|
|
97
|
+
have a trusted publisher configured for this repository, the `release.yml`
|
|
98
|
+
workflow, and the `pypi` GitHub environment.
|
|
@@ -0,0 +1,104 @@
|
|
|
1
|
+
# Guide (user-friendly):
|
|
2
|
+
# https://packaging.python.org/en/latest/guides/writing-pyproject-toml/
|
|
3
|
+
|
|
4
|
+
# Specification (technical, formal):
|
|
5
|
+
# https://packaging.python.org/en/latest/specifications/pyproject-toml/
|
|
6
|
+
|
|
7
|
+
|
|
8
|
+
# Choosing a build backend:
|
|
9
|
+
# https://packaging.python.org/en/latest/tutorials/packaging-projects/#choosing-a-build-backend
|
|
10
|
+
[build-system]
|
|
11
|
+
# A list of packages that are needed to build your package:
|
|
12
|
+
requires = ["setuptools", "setuptools-scm>=8"] # REQUIRED if [build-system] table is used
|
|
13
|
+
# The name of the Python object that frontends will use to perform the build:
|
|
14
|
+
build-backend = "setuptools.build_meta" # If not defined, then legacy behavior can happen.
|
|
15
|
+
|
|
16
|
+
|
|
17
|
+
[project]
|
|
18
|
+
# https://packaging.python.org/specifications/core-metadata/#name
|
|
19
|
+
name = "lambda-api-decorators-cdk"
|
|
20
|
+
# https://packaging.python.org/guides/single-sourcing-package-version/
|
|
21
|
+
dynamic = ["version"]
|
|
22
|
+
|
|
23
|
+
# https://packaging.python.org/specifications/core-metadata/#summary
|
|
24
|
+
description = "AWS CDK integration for Lambda API Decorators. Generate AWS Lambda and API Gateway infrastructure from decorated Python handlers."
|
|
25
|
+
|
|
26
|
+
# https://packaging.python.org/specifications/core-metadata/#description-optional
|
|
27
|
+
readme = "README.md"
|
|
28
|
+
|
|
29
|
+
# https://packaging.python.org/guides/distributing-packages-using-setuptools/#python-requires
|
|
30
|
+
requires-python = ">=3.9"
|
|
31
|
+
|
|
32
|
+
|
|
33
|
+
# https://packaging.python.org/en/latest/specifications/core-metadata/#license
|
|
34
|
+
license = {file = "LICENSE"}
|
|
35
|
+
|
|
36
|
+
keywords = ["cdk", "lambda", "aws", "api gateway", "ast"]
|
|
37
|
+
|
|
38
|
+
authors = [
|
|
39
|
+
{name = "Mateo Marcos"},
|
|
40
|
+
{name = "Emanuel Arguinarena"},
|
|
41
|
+
{name = "Lucas Picchi"}
|
|
42
|
+
]
|
|
43
|
+
|
|
44
|
+
#maintainers = [
|
|
45
|
+
# {name = "A. Great Maintainer", email = "maintainer@example.com" }
|
|
46
|
+
#]
|
|
47
|
+
|
|
48
|
+
|
|
49
|
+
# For a list of valid classifiers, see https://pypi.org/classifiers/
|
|
50
|
+
classifiers = [
|
|
51
|
+
'Development Status :: 2 - Pre-Alpha',
|
|
52
|
+
'Intended Audience :: Developers',
|
|
53
|
+
'Framework :: AWS CDK :: 2',
|
|
54
|
+
'Topic :: Software Development :: Libraries :: Python Modules',
|
|
55
|
+
'Topic :: Software Development :: Build Tools',
|
|
56
|
+
'License :: OSI Approved :: MIT License',
|
|
57
|
+
'Programming Language :: Python :: 3.9',
|
|
58
|
+
'Programming Language :: Python :: 3.10',
|
|
59
|
+
'Programming Language :: Python :: 3.11',
|
|
60
|
+
'Programming Language :: Python :: 3.12'
|
|
61
|
+
]
|
|
62
|
+
|
|
63
|
+
# For an analysis of this field vs pip's requirements files see:
|
|
64
|
+
# https://packaging.python.org/discussions/install-requires-vs-requirements/
|
|
65
|
+
dependencies = [
|
|
66
|
+
"aws-cdk.aws-lambda-python-alpha"
|
|
67
|
+
]
|
|
68
|
+
|
|
69
|
+
|
|
70
|
+
# https://packaging.python.org/en/latest/specifications/dependency-specifiers/#extras
|
|
71
|
+
#[project.optional-dependencies]
|
|
72
|
+
#dev = ["check-manifest"]
|
|
73
|
+
#test = ["coverage"]
|
|
74
|
+
|
|
75
|
+
# List URLs that are relevant to your project
|
|
76
|
+
#
|
|
77
|
+
# This field corresponds to the "Project-URL" and "Home-Page" metadata fields:
|
|
78
|
+
# https://packaging.python.org/specifications/core-metadata/#project-url-multiple-use
|
|
79
|
+
# https://packaging.python.org/specifications/core-metadata/#home-page-optional
|
|
80
|
+
#
|
|
81
|
+
# Examples listed include a pattern for specifying where the package tracks
|
|
82
|
+
# issues, where the source is hosted, where to say thanks to the package
|
|
83
|
+
# maintainers, and where to support the project financially. The key is
|
|
84
|
+
# what's used to render the link text on PyPI.
|
|
85
|
+
[project.urls]
|
|
86
|
+
"Homepage" = "https://github.com/lambda-api-decorators/lambda-api-decorators-cdk"
|
|
87
|
+
"Repository" = "https://github.com/lambda-api-decorators/lambda-api-decorators-cdk"
|
|
88
|
+
"Bug Reports" = "https://github.com/lambda-api-decorators/lambda-api-decorators-cdk"
|
|
89
|
+
|
|
90
|
+
# The following would provide a command line executable called `sample`
|
|
91
|
+
# which executes the function `main` from this package when invoked.
|
|
92
|
+
#[project.scripts]
|
|
93
|
+
#sample = "sample:main"
|
|
94
|
+
|
|
95
|
+
|
|
96
|
+
# This is configuration specific to the `setuptools` build backend.
|
|
97
|
+
# If you are using a different build backend, you will need to change this.
|
|
98
|
+
[tool.setuptools]
|
|
99
|
+
|
|
100
|
+
[tool.setuptools_scm]
|
|
101
|
+
tag_regex = '^v(?P<version>[0-9]+\.[0-9]+\.[0-9]+)$'
|
|
102
|
+
|
|
103
|
+
[tool.pytest.ini_options]
|
|
104
|
+
pythonpath = ["src"]
|