2018-07-06 00:57:23 +00:00
|
|
|
#!/usr/bin/env python
|
|
|
|
#
|
2022-04-12 15:42:41 +00:00
|
|
|
# tractor: structured concurrent "actors".
|
2018-07-06 00:57:23 +00:00
|
|
|
#
|
2022-04-12 15:42:41 +00:00
|
|
|
# Copyright 2018-eternity Tyler Goodlet.
|
2018-07-06 00:57:23 +00:00
|
|
|
|
|
|
|
# This program is free software: you can redistribute it and/or modify
|
2022-04-12 15:42:41 +00:00
|
|
|
# it under the terms of the GNU Affero General Public License as published by
|
2018-07-06 00:57:23 +00:00
|
|
|
# the Free Software Foundation, either version 3 of the License, or
|
|
|
|
# (at your option) any later version.
|
|
|
|
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
2022-04-12 15:42:41 +00:00
|
|
|
# GNU Affero General Public License for more details.
|
|
|
|
|
|
|
|
# You should have received a copy of the GNU Affero General Public License
|
|
|
|
# along with this program. If not, see <https://www.gnu.org/licenses/>.
|
2018-07-06 00:57:23 +00:00
|
|
|
|
|
|
|
from setuptools import setup
|
|
|
|
|
2021-02-21 22:47:06 +00:00
|
|
|
with open('docs/README.rst', encoding='utf-8') as f:
|
2018-07-06 00:57:23 +00:00
|
|
|
readme = f.read()
|
|
|
|
|
|
|
|
|
|
|
|
setup(
|
|
|
|
name="tractor",
|
2022-08-03 18:38:32 +00:00
|
|
|
version='0.1.0a6dev0', # alpha zone
|
2024-02-20 20:29:31 +00:00
|
|
|
description='structured concurrent `trio`-"actors"',
|
2018-07-06 00:57:23 +00:00
|
|
|
long_description=readme,
|
2022-04-12 15:42:41 +00:00
|
|
|
license='AGPLv3',
|
2018-07-06 00:57:23 +00:00
|
|
|
author='Tyler Goodlet',
|
|
|
|
maintainer='Tyler Goodlet',
|
2023-04-15 23:43:20 +00:00
|
|
|
maintainer_email='goodboy_foss@protonmail.com',
|
2019-04-28 14:41:24 +00:00
|
|
|
url='https://github.com/goodboy/tractor',
|
2019-11-16 14:58:06 +00:00
|
|
|
platforms=['linux', 'windows'],
|
2018-07-06 00:57:23 +00:00
|
|
|
packages=[
|
|
|
|
'tractor',
|
2024-03-06 14:48:46 +00:00
|
|
|
'tractor.experimental', # wacky ideas
|
|
|
|
'tractor.trionics', # trio extensions
|
|
|
|
'tractor.msg', # lowlevel data types
|
2024-03-06 14:55:05 +00:00
|
|
|
'tractor.devx', # "dev-experience"
|
2018-07-06 00:57:23 +00:00
|
|
|
],
|
2019-01-16 18:41:49 +00:00
|
|
|
install_requires=[
|
2021-07-02 15:56:14 +00:00
|
|
|
|
|
|
|
# trio related
|
2022-10-09 17:03:52 +00:00
|
|
|
# proper range spec:
|
|
|
|
# https://packaging.python.org/en/latest/discussions/install-requires-vs-requirements/#id5
|
2024-03-13 20:21:30 +00:00
|
|
|
'trio >= 0.24',
|
2024-03-13 22:41:24 +00:00
|
|
|
|
|
|
|
# 'async_generator', # in stdlib mostly!
|
|
|
|
# 'trio_typing', # trio==0.23.0 has type hints!
|
|
|
|
# 'exceptiongroup', # in stdlib as of 3.11!
|
2021-07-02 15:56:14 +00:00
|
|
|
|
|
|
|
# tooling
|
2024-02-20 20:29:31 +00:00
|
|
|
'stackscope',
|
2021-06-11 20:20:35 +00:00
|
|
|
'tricycle',
|
|
|
|
'trio_typing',
|
2021-02-26 04:51:53 +00:00
|
|
|
'colorlog',
|
|
|
|
'wrapt',
|
2022-07-10 21:36:39 +00:00
|
|
|
|
2023-04-15 23:43:20 +00:00
|
|
|
# IPC serialization
|
Init def of "SC shuttle prot" with "msg-spec-limiting"
As per the long outstanding GH issue this starts our rigorous journey
into an attempt at a type-safe, cross-actor SC, IPC protocol Bo
boop -> https://github.com/goodboy/tractor/issues/36
The idea is to "formally" define our SC "shuttle (dialog) protocol" by
specifying a new `.msg.types.Msg` subtype-set which can fully
encapsulate all IPC msg schemas needed in order to accomplish
cross-process SC!
The msg set deviated a little in terms of (type) names from the existing
`dict`-msgs currently used in the runtime impl but, I think the name
changes are much better in terms of explicitly representing the internal
semantics of the actor runtime machinery/subsystems and the
IPC-msg-dialog required for SC enforced RPC.
------ - ------
In cursory, the new formal msgs-spec includes the following msg-subtypes
of a new top-level `Msg` boxing type (that holds the base field schema
for all msgs):
- `Start` to request RPC task scheduling by passing a `FuncSpec` payload
(to replace the currently used `{'cmd': ... }` dict msg impl)
- `StartAck` to allow the RPC task callee-side to report a `IpcCtxSpec`
payload immediately back to the caller (currently responded naively via
a `{'functype': ... }` msg)
- `Started` to deliver the first value from `Context.started()`
(instead of the existing `{'started': ... }`)
- `Yield` to shuttle `MsgStream.send()`-ed values (instead of
our `{'yield': ... }`)
- `Stop` to terminate a `Context.open_stream()` session/block
(over `{'stop': True }`)
- `Return` to deliver the final value from the `Actor.start_remote_task()`
(which is a `{'return': ... }`)
- `Error` to box `RemoteActorError` exceptions via a `.pld: ErrorData`
payload, planned to replace/extend the current `RemoteActorError.msgdata`
mechanism internal to `._exceptions.pack/unpack_error()`
The new `tractor.msg.types` includes all the above msg defs as well an API
for rendering a "payload type specification" using a
`payload_type_spec: Union[Type]` that can be passed to
`msgspec.msgpack.Decoder(type=payload_type_spec)`. This ensures that
(for a subset of the above msg set) `Msg.pld: PayloadT` data is
type-parameterized using `msgspec`'s new `Generic[PayloadT]` field
support and thus enables providing for an API where IPC `Context`
dialogs can strictly define the allowed payload-datatype-set via type
union!
Iow, this is the foundation for supporting `Channel`/`Context`/`MsgStream`
IPC primitives which are type checked/safe as desired in GH issue:
- https://github.com/goodboy/tractor/issues/365
Misc notes on current impl(s) status:
------ - ------
- add a `.msg.types.mk_msg_spec()` which uses the new `msgspec` support
for `class MyStruct[Struct, Generic[T]]` parameterize-able fields and
delivers our boxing SC-msg-(sub)set with the desired `payload_types`
applied to `.pld`:
- https://jcristharif.com/msgspec/supported-types.html#generic-types
- as a note this impl seems to need to use `type.new_class()` dynamic
subtype generation, though i don't really get *why* still.. but
without that the `msgspec.msgpack.Decoder` doesn't seem to reject
`.pld` limited `Msg` subtypes as demonstrated in the new test.
- around this ^ add a `.msg._codec.limit_msg_spec()` cm which exposes
this payload type limiting API such that it can be applied per task
via a `MsgCodec` in app code.
- the orig approach in https://github.com/goodboy/tractor/pull/311 was
the idea of making payload fields `.pld: Raw` wherein we could have
per-field/sub-msg decoders dynamically loaded depending on the
particular application-layer schema in use. I don't want to lose the
idea of this since I think it might be useful for an idea I have about
capability-based-fields(-sharing, maybe using field-subset
encryption?), and as such i've kept the (ostensibly) working impls in
TODO-comments in `.msg._codec` wherein maybe we can add
a `MsgCodec._payload_decs: dict` table for this later on.
|_ also left in the `.msg.types.enc/decmsg()` impls but renamed as
`enc/dec_payload()` (but reworked to not rely on the lifo codec
stack tables; now removed) such that we can prolly move them to
`MsgCodec` methods in the future.
- add an unused `._codec.mk_tagged_union_dec()` helper which was
originally factored out the #311 proto-code but didn't end up working
as desired with the new parameterized generic fields approach (now
in `msg.types.mk_msg_spec()`)
Testing/deps work:
------ - ------
- new `test_limit_msgspec()` which ensures all the `.types` content is
correct but without using the wrapping APIs in `._codec`; i.e. using
a in-line `Decoder` instead of a `MsgCodec`.
- pin us to `msgspec>=0.18.5` which has the needed generic-types support
(which took me way too long yester to figure out when implementing all
this XD)!
2024-03-28 14:45:01 +00:00
|
|
|
'msgspec>=0.18.5',
|
2022-08-03 18:28:21 +00:00
|
|
|
|
2023-01-26 20:27:55 +00:00
|
|
|
# debug mode REPL
|
2023-04-15 23:43:20 +00:00
|
|
|
'pdbp',
|
2023-01-26 20:27:55 +00:00
|
|
|
|
2024-02-20 20:29:31 +00:00
|
|
|
# TODO: distributed transport using
|
|
|
|
# linux kernel networking
|
|
|
|
# 'pyroute2',
|
|
|
|
|
2022-07-10 21:36:39 +00:00
|
|
|
# pip ref docs on these specs:
|
|
|
|
# https://pip.pypa.io/en/stable/reference/requirement-specifiers/#examples
|
|
|
|
# and pep:
|
|
|
|
# https://peps.python.org/pep-0440/#version-specifiers
|
|
|
|
|
2022-07-12 00:22:33 +00:00
|
|
|
],
|
2018-07-06 00:57:23 +00:00
|
|
|
tests_require=['pytest'],
|
2023-04-15 23:43:20 +00:00
|
|
|
python_requires=">=3.10",
|
2018-07-06 00:57:23 +00:00
|
|
|
keywords=[
|
2021-02-26 04:51:53 +00:00
|
|
|
'trio',
|
2022-07-12 00:22:33 +00:00
|
|
|
'async',
|
|
|
|
'concurrency',
|
|
|
|
'structured concurrency',
|
|
|
|
'actor model',
|
|
|
|
'distributed',
|
2021-02-26 04:51:53 +00:00
|
|
|
'multiprocessing'
|
2018-07-06 00:57:23 +00:00
|
|
|
],
|
|
|
|
classifiers=[
|
2021-02-27 21:08:14 +00:00
|
|
|
"Development Status :: 3 - Alpha",
|
|
|
|
"Operating System :: POSIX :: Linux",
|
|
|
|
"Operating System :: Microsoft :: Windows",
|
2018-07-10 21:27:47 +00:00
|
|
|
"Framework :: Trio",
|
2022-04-12 15:42:41 +00:00
|
|
|
"License :: OSI Approved :: GNU Affero General Public License v3 or later (AGPLv3+)",
|
2018-07-06 00:57:23 +00:00
|
|
|
"Programming Language :: Python :: Implementation :: CPython",
|
|
|
|
"Programming Language :: Python :: 3 :: Only",
|
2022-07-11 15:19:44 +00:00
|
|
|
"Programming Language :: Python :: 3.10",
|
2018-07-10 21:27:47 +00:00
|
|
|
"Intended Audience :: Science/Research",
|
|
|
|
"Intended Audience :: Developers",
|
|
|
|
"Topic :: System :: Distributed Computing",
|
2018-07-06 00:57:23 +00:00
|
|
|
],
|
|
|
|
)
|