9f6a135702
* refactor python http template * python http scaffolding * add python to make update-runtimes * integrate python scaffolding with func run * python http template * reorganize python scaffolding * cancellation stopgap * documentation and logging cleanup * Python Middleware v2 - Scaffolding * base layer cache * remove wsgi and flask templates Inbuilt templates should be limited to a base http and cloudevent integration, with anything beyond this falling to the officially supported functions samples repository. * update python cloudevents runtime in makefile * python cloudevents middleware * add python .venvs to gitignore * clean up venvs on make * add missing dependencies to python http tempklate * set python cloudevents manifest * further cleanup of repository impl * cleanup * ignore venv when building runtime container * set listen address on python container * remove unnecessary python runtime update from makefile * remove debug statements and improved comments * enable scaffolding python funcs in s2i builder * set listen address on all containers built by s2i * python s2i integration * regen fs * cleanup * enable host builder * fix manifest inheritance * regen fs * bug fixes * regen docs * cleanup and linter error fixes * conditional python host builder test * misspellings * disable python E2E Until the Python middleware is supported by the Pack builder, the E2E tests will need to be disabled. * install python for presubmit tests * use linux for test builder runs The target platform for a test needs to be a platform which is available in all test base images. That's usually linux. Using current OS would fail, for example, building python containers on MacOS because the official Python base image has no darwin layer. * fix ineffasign * set python ce template to python 3.9 * regen fs * windows python tests * python templates README |
||
|---|---|---|
| .. | ||
| instanced-cloudevents | ||
| instanced-http | ||
| README.md | ||
README.md
Python Scaffolding
The scaffolding for Python packages consist of one directory for each of the various invocation methods; currently "http" (default) and "cloudevents".
There are different method signatures and underlying middleware implementations for each; hence the separation.
Note that the "instanced" versions also support static, thus only they are included:
Each of the two support either the instanced method signature ("new") or the static "handle" method. This differs from strongly typed languages such as Go which require different scaffolding be written based on this division. This is because as a dynamically typed language, we can inspect the user's function at runtime and import either their "handle" or "new" depending on which was implemented. Therefore the Python scaffolding moves the complexity into the middleware, rather than relying on the scaffolding process of func to do static code analysis.