# systemPY
![Logo](https://raw.githubusercontent.com/kai3341/systemPY/main/docs/images/systempy-logo.png)
Python application component initialization system
![python](https://img.shields.io/pypi/pyversions/systemPY)
![version](https://img.shields.io/pypi/v/systemPY)
![downloads](https://img.shields.io/pypi/dm/systemPY)
![format](https://img.shields.io/pypi/format/systemPY)
[![Documentation Status](https://readthedocs.org/projects/systempy/badge/?version=latest)](https://systempy.readthedocs.io/en/latest/?badge=latest)
![GitHub issues](https://img.shields.io/github/issues/kai3341/systemPY)
Full documantation is available at
[Read the Docs](https://systempy.readthedocs.io/en/latest/)
## The problem
The regular application contain many atomic components. Asyncio makes theirs
initializing a little bit complicated. It's OK, when you have single entrypoint
and initialize your application components via your framework. While you add
new components to your application iteratively, you don't see any problem
When you create any new entrypoint, you have to think a lot, how to initialize
application components again, which callbacks should be called and in which
order. But it's a half of the problem! You have to implement also graceful
shutdown
The most painful part is one-time scripts. It's kind of The Banana Gorilla
Problem: you wanted a banana but you have to initialize a gorilla holding the
banana and the entire jungle, and then graceful shutdown it
## Solution
This library allows you to implement application startup and shutdown in
declarative way. You have to implement a class for each your component,
write the startup and shutdown code. Then combine required components as
mixins into the current application `Unit` class. Then create an instance
and pass dependencies as keyword arguments. In case it's daemon run
`instance.run_sync()` methed
## Basic principles
There are 6 most significant stages of the application lifecycle:
* `on_init` executes exactly once on application startup
* `pre_startup` is called before event loop startup
* `on_startup` is called exactly when event loop started
* `on_shutdown` is called when application is going shutdown or reload but
event loop still working
* `post_shutdown` is called after event loop stopped or drained. When
application is going to reload, then it should be called `pre_startup`
* `on_exit` executes exactly once when application is stopping
You may to create `Unit` classes for each your application component where you
may put your code. Then you may combine these `Unit` class mixins into the
current worker class, which aggregate your defined callbacks and run in the
right order. Depending on application type, these callbacks may be called by
primary application or by you are
Raw data
{
"_id": null,
"home_page": "https://github.com/kai3341/systemPY",
"name": "systemPY",
"maintainer": "",
"docs_url": null,
"requires_python": "",
"maintainer_email": "",
"keywords": "asyncio,graceful,init,initialization,shutdown,manager",
"author": "",
"author_email": "",
"download_url": "https://files.pythonhosted.org/packages/62/f1/fde6c4ac36bd95617bb246a18b8f256d20dfaac07f83aa16b15297b4e17c/systemPY-0.0.16.tar.gz",
"platform": null,
"description": "# systemPY\n\n![Logo](https://raw.githubusercontent.com/kai3341/systemPY/main/docs/images/systempy-logo.png)\n\nPython application component initialization system\n\n![python](https://img.shields.io/pypi/pyversions/systemPY)\n![version](https://img.shields.io/pypi/v/systemPY)\n![downloads](https://img.shields.io/pypi/dm/systemPY)\n![format](https://img.shields.io/pypi/format/systemPY)\n[![Documentation Status](https://readthedocs.org/projects/systempy/badge/?version=latest)](https://systempy.readthedocs.io/en/latest/?badge=latest)\n![GitHub issues](https://img.shields.io/github/issues/kai3341/systemPY)\n\nFull documantation is available at\n[Read the Docs](https://systempy.readthedocs.io/en/latest/)\n\n## The problem\n\nThe regular application contain many atomic components. Asyncio makes theirs\ninitializing a little bit complicated. It's OK, when you have single entrypoint\nand initialize your application components via your framework. While you add\nnew components to your application iteratively, you don't see any problem\n\nWhen you create any new entrypoint, you have to think a lot, how to initialize\napplication components again, which callbacks should be called and in which\norder. But it's a half of the problem! You have to implement also graceful\nshutdown\n\nThe most painful part is one-time scripts. It's kind of The Banana Gorilla\nProblem: you wanted a banana but you have to initialize a gorilla holding the\nbanana and the entire jungle, and then graceful shutdown it\n\n## Solution\n\nThis library allows you to implement application startup and shutdown in\ndeclarative way. You have to implement a class for each your component,\nwrite the startup and shutdown code. Then combine required components as\nmixins into the current application `Unit` class. Then create an instance\nand pass dependencies as keyword arguments. In case it's daemon run\n`instance.run_sync()` methed\n\n## Basic principles\n\nThere are 6 most significant stages of the application lifecycle:\n\n* `on_init` executes exactly once on application startup\n\n* `pre_startup` is called before event loop startup\n\n* `on_startup` is called exactly when event loop started\n\n* `on_shutdown` is called when application is going shutdown or reload but\nevent loop still working\n\n* `post_shutdown` is called after event loop stopped or drained. When\napplication is going to reload, then it should be called `pre_startup`\n\n* `on_exit` executes exactly once when application is stopping\n\nYou may to create `Unit` classes for each your application component where you\nmay put your code. Then you may combine these `Unit` class mixins into the\ncurrent worker class, which aggregate your defined callbacks and run in the\nright order. Depending on application type, these callbacks may be called by\nprimary application or by you are\n\n\n",
"bugtrack_url": null,
"license": "MIT",
"summary": "Python application component initialization system",
"version": "0.0.16",
"project_urls": {
"Homepage": "https://github.com/kai3341/systemPY"
},
"split_keywords": [
"asyncio",
"graceful",
"init",
"initialization",
"shutdown",
"manager"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "9d15e8b522c39159582f7177bcffb1baaf2e3dd2d4d32600b00b2d6ff4e0a8cd",
"md5": "7718a8b3142a4a1ce97646c9b7c75657",
"sha256": "de33489b8cc9af71d4fddf8c03f222032af9dbe7141412127a0dc4554c5c1491"
},
"downloads": -1,
"filename": "systemPY-0.0.16-py3-none-any.whl",
"has_sig": false,
"md5_digest": "7718a8b3142a4a1ce97646c9b7c75657",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": null,
"size": 25648,
"upload_time": "2023-06-27T04:14:59",
"upload_time_iso_8601": "2023-06-27T04:14:59.089733Z",
"url": "https://files.pythonhosted.org/packages/9d/15/e8b522c39159582f7177bcffb1baaf2e3dd2d4d32600b00b2d6ff4e0a8cd/systemPY-0.0.16-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "62f1fde6c4ac36bd95617bb246a18b8f256d20dfaac07f83aa16b15297b4e17c",
"md5": "aaf268e11f31d6730ecad66f156fb99e",
"sha256": "5ecad5aaf4254eb4f11819cbfea83c03a1010e69893a1ea13196b1bdb1cfbb3c"
},
"downloads": -1,
"filename": "systemPY-0.0.16.tar.gz",
"has_sig": false,
"md5_digest": "aaf268e11f31d6730ecad66f156fb99e",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 14239,
"upload_time": "2023-06-27T04:15:00",
"upload_time_iso_8601": "2023-06-27T04:15:00.955693Z",
"url": "https://files.pythonhosted.org/packages/62/f1/fde6c4ac36bd95617bb246a18b8f256d20dfaac07f83aa16b15297b4e17c/systemPY-0.0.16.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2023-06-27 04:15:00",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "kai3341",
"github_project": "systemPY",
"travis_ci": false,
"coveralls": false,
"github_actions": false,
"lcname": "systempy"
}