diff options
| author | CoprDistGit <infra@openeuler.org> | 2023-05-05 05:31:42 +0000 |
|---|---|---|
| committer | CoprDistGit <infra@openeuler.org> | 2023-05-05 05:31:42 +0000 |
| commit | 3733934919adc79052acd57f73f6c74a01108444 (patch) | |
| tree | 35a4f383329fafe375af0a569d8bf1c9a6a720fd /python-eventy.spec | |
| parent | 8a7063b8988031acfa3ee9a84b01904e4a83e66e (diff) | |
automatic import of python-eventyopeneuler20.03
Diffstat (limited to 'python-eventy.spec')
| -rw-r--r-- | python-eventy.spec | 389 |
1 files changed, 389 insertions, 0 deletions
diff --git a/python-eventy.spec b/python-eventy.spec new file mode 100644 index 0000000..89d7f81 --- /dev/null +++ b/python-eventy.spec @@ -0,0 +1,389 @@ +%global _empty_manifest_terminate_build 0 +Name: python-eventy +Version: 3.3.0 +Release: 1 +Summary: Qotto/eventy +License: MIT +URL: https://gitlab.com/qotto/oss/eventy +Source0: https://mirrors.nju.edu.cn/pypi/web/packages/aa/d4/c9772d7936fc6561a15c05780df6c3f0ebbd240ef8310b09c679e932329b/eventy-3.3.0.tar.gz +BuildArch: noarch + +Requires: python3-semver +Requires: python3-coloredlogs +Requires: python3-contextvars +Requires: python3-PyYAML +Requires: python3-avro-python3 +Requires: python3-celery +Requires: python3-sanic +Requires: python3-aiohttp +Requires: python3-django +Requires: python3-confluent-kafka +Requires: python3-requests + +%description +# Eventy + +* Source: [Eventy on GitLab](https://gitlab.com/qotto/oss/eventy) +* Package: [Eventy on Pypi](https://pypi.org/project/eventy/) +* Documentation: [Eventy API documentation](https://qotto.gitlab.io/oss/eventy/) + +## What is Eventy? + +Eventy is both a protocol and a library for making the design of fault-tolerant, event-driven, concurrent and +distributed applications in a microservices-oriented architecture easier. + +As a protocol, Eventy is language-agnostic. + +However, the reference implementation is written in Python. Whatever is your programming language, you can use Eventy. +If you are using Python, you will be able to make the most of it quicker. + +## Motivation + +The reality is, a distributed, microservices-oriented architecture is a bit hard to make right. + +Martin Fowler even [ended up stating](https://www.drdobbs.com/errant-architectures/184414966): + +> First Law of Distributed Object Design: “don't distribute your objects”. + +He later [detailed his view](https://martinfowler.com/articles/distributed-objects-microservices.html) of the First Law +regarding microservices. + +As Martin Folwer points out, inherently microservices come with their undeniable advantages and a few companies use them +with great success. The only reason why a lot of people end up struggling with microservices, is because it greatly +increases the complexity of the whole system, which makes it harder to get it right. + +Eventy is adressing exactly that issue — providing you with a reliable framework to make microservices work for you. + +A big part of the design process to create Eventy was to understand different use cases and see how the design can be +simplified. For instance, not only does Eventy offer state partitionning for free, it actually comes up with a few +stratagies that eliminate the need to persist state altogether. + +## Inspiration + +[Kafka Streams](https://kafka.apache.org/documentation/streams/) was a great influence in making +Eventy. [Celery](http://www.celeryproject.org/) and [Faust](https://github.com/robinhood/faust) are also worth to be +looked at if you are looking for an opiniated framework easy to get started with. + +However, these frameworks only partially solve all the issues you will have with microservices. And, in our opinion, +these frameworks are not suitable for designing large critical systems. + +They're both opinanated, and therefore cannot be easily integrated in your existing software. You will have to build +your software around the framework, instead of the other way around. They also don't give you the full control on the +way you can use them: you can only use them as a whole, or not at all. + +## What Eventy can do for you + +Eventy implements multiple features, but all of them simply solve two main problems: + +* How to make services communicate with each other +* How to access and persist state + +With Eventy, you can serialize data the way you want. You can use [Avro](https://avro.apache.org/) +, [JSON](https://www.json.org/), [gRPC](https://grpc.io/), or whatever customer serializer you like. + +With Eventy, you can use any system you like as a persistency layer, as long as it supports transactions, if you need +strong processing guarantees. The most obvious choice is to use [Apache Kafka](https://kafka.apache.org/), but +persisting messages over [PostgreSQL](https://www.postgresql.org/) is completely feasable, too. + +Eventy was destined with the mindset of a library of related but independently usable components - and not a framework: +the behaviour is explicit and you're the one in charge: you can design your software your own way. + +This explicit behaviour, albeit requiring more boilerplate, gives you better clarity on what is happening. Recipes and +examples are provided so that you can understand how to use Eventy for most use cases. + +You're free to use any part of Eventy as well. Even if you end up not using the Eventy protocol at all, simply reading +the documentation and understanding the issues that are adressed and how they are adressed can help you to get on the +right path. + +## Main components of Eventy + +* a **well-defined communication protocol** for sending various types of persisted messages, called _Records_: _Events_ + , _Requests_ and _Responses_ +* **persistency of _Records_** that can be stored forever, which lets you keep track of all the changes in your system ( + especially useful for audits and business analytics) +* **queues** so that _Records_ can be processed asynchroneously, and aren't lost even if your system is down or + overloaded +* **strong processing guarantees**: a Record can be designed to be processed _at least once_, _at most once_ and _ + exactly once_ even if your system encounters a process or network failure at any point +* **self-propagating _Contexts_** that in many cases entirely eliminate the need of persisting state +* **partitionned state persistency** so that you no longer have a single point of failure in your system (aka _the + database_) and can scale up as your business grows + +# Contribute + +Install with dev dependencies + +``` +poetry install -E celery -E sanic -E aiohttp -E django -E confluent-kafka -E avro -E requests +``` + +The project uses [poetry](https://python-poetry.org/) + +``` +poetry config pypi-token.pypi my-token +poetry config testpypi-token.pypi my-token +``` + + +%package -n python3-eventy +Summary: Qotto/eventy +Provides: python-eventy +BuildRequires: python3-devel +BuildRequires: python3-setuptools +BuildRequires: python3-pip +%description -n python3-eventy +# Eventy + +* Source: [Eventy on GitLab](https://gitlab.com/qotto/oss/eventy) +* Package: [Eventy on Pypi](https://pypi.org/project/eventy/) +* Documentation: [Eventy API documentation](https://qotto.gitlab.io/oss/eventy/) + +## What is Eventy? + +Eventy is both a protocol and a library for making the design of fault-tolerant, event-driven, concurrent and +distributed applications in a microservices-oriented architecture easier. + +As a protocol, Eventy is language-agnostic. + +However, the reference implementation is written in Python. Whatever is your programming language, you can use Eventy. +If you are using Python, you will be able to make the most of it quicker. + +## Motivation + +The reality is, a distributed, microservices-oriented architecture is a bit hard to make right. + +Martin Fowler even [ended up stating](https://www.drdobbs.com/errant-architectures/184414966): + +> First Law of Distributed Object Design: “don't distribute your objects”. + +He later [detailed his view](https://martinfowler.com/articles/distributed-objects-microservices.html) of the First Law +regarding microservices. + +As Martin Folwer points out, inherently microservices come with their undeniable advantages and a few companies use them +with great success. The only reason why a lot of people end up struggling with microservices, is because it greatly +increases the complexity of the whole system, which makes it harder to get it right. + +Eventy is adressing exactly that issue — providing you with a reliable framework to make microservices work for you. + +A big part of the design process to create Eventy was to understand different use cases and see how the design can be +simplified. For instance, not only does Eventy offer state partitionning for free, it actually comes up with a few +stratagies that eliminate the need to persist state altogether. + +## Inspiration + +[Kafka Streams](https://kafka.apache.org/documentation/streams/) was a great influence in making +Eventy. [Celery](http://www.celeryproject.org/) and [Faust](https://github.com/robinhood/faust) are also worth to be +looked at if you are looking for an opiniated framework easy to get started with. + +However, these frameworks only partially solve all the issues you will have with microservices. And, in our opinion, +these frameworks are not suitable for designing large critical systems. + +They're both opinanated, and therefore cannot be easily integrated in your existing software. You will have to build +your software around the framework, instead of the other way around. They also don't give you the full control on the +way you can use them: you can only use them as a whole, or not at all. + +## What Eventy can do for you + +Eventy implements multiple features, but all of them simply solve two main problems: + +* How to make services communicate with each other +* How to access and persist state + +With Eventy, you can serialize data the way you want. You can use [Avro](https://avro.apache.org/) +, [JSON](https://www.json.org/), [gRPC](https://grpc.io/), or whatever customer serializer you like. + +With Eventy, you can use any system you like as a persistency layer, as long as it supports transactions, if you need +strong processing guarantees. The most obvious choice is to use [Apache Kafka](https://kafka.apache.org/), but +persisting messages over [PostgreSQL](https://www.postgresql.org/) is completely feasable, too. + +Eventy was destined with the mindset of a library of related but independently usable components - and not a framework: +the behaviour is explicit and you're the one in charge: you can design your software your own way. + +This explicit behaviour, albeit requiring more boilerplate, gives you better clarity on what is happening. Recipes and +examples are provided so that you can understand how to use Eventy for most use cases. + +You're free to use any part of Eventy as well. Even if you end up not using the Eventy protocol at all, simply reading +the documentation and understanding the issues that are adressed and how they are adressed can help you to get on the +right path. + +## Main components of Eventy + +* a **well-defined communication protocol** for sending various types of persisted messages, called _Records_: _Events_ + , _Requests_ and _Responses_ +* **persistency of _Records_** that can be stored forever, which lets you keep track of all the changes in your system ( + especially useful for audits and business analytics) +* **queues** so that _Records_ can be processed asynchroneously, and aren't lost even if your system is down or + overloaded +* **strong processing guarantees**: a Record can be designed to be processed _at least once_, _at most once_ and _ + exactly once_ even if your system encounters a process or network failure at any point +* **self-propagating _Contexts_** that in many cases entirely eliminate the need of persisting state +* **partitionned state persistency** so that you no longer have a single point of failure in your system (aka _the + database_) and can scale up as your business grows + +# Contribute + +Install with dev dependencies + +``` +poetry install -E celery -E sanic -E aiohttp -E django -E confluent-kafka -E avro -E requests +``` + +The project uses [poetry](https://python-poetry.org/) + +``` +poetry config pypi-token.pypi my-token +poetry config testpypi-token.pypi my-token +``` + + +%package help +Summary: Development documents and examples for eventy +Provides: python3-eventy-doc +%description help +# Eventy + +* Source: [Eventy on GitLab](https://gitlab.com/qotto/oss/eventy) +* Package: [Eventy on Pypi](https://pypi.org/project/eventy/) +* Documentation: [Eventy API documentation](https://qotto.gitlab.io/oss/eventy/) + +## What is Eventy? + +Eventy is both a protocol and a library for making the design of fault-tolerant, event-driven, concurrent and +distributed applications in a microservices-oriented architecture easier. + +As a protocol, Eventy is language-agnostic. + +However, the reference implementation is written in Python. Whatever is your programming language, you can use Eventy. +If you are using Python, you will be able to make the most of it quicker. + +## Motivation + +The reality is, a distributed, microservices-oriented architecture is a bit hard to make right. + +Martin Fowler even [ended up stating](https://www.drdobbs.com/errant-architectures/184414966): + +> First Law of Distributed Object Design: “don't distribute your objects”. + +He later [detailed his view](https://martinfowler.com/articles/distributed-objects-microservices.html) of the First Law +regarding microservices. + +As Martin Folwer points out, inherently microservices come with their undeniable advantages and a few companies use them +with great success. The only reason why a lot of people end up struggling with microservices, is because it greatly +increases the complexity of the whole system, which makes it harder to get it right. + +Eventy is adressing exactly that issue — providing you with a reliable framework to make microservices work for you. + +A big part of the design process to create Eventy was to understand different use cases and see how the design can be +simplified. For instance, not only does Eventy offer state partitionning for free, it actually comes up with a few +stratagies that eliminate the need to persist state altogether. + +## Inspiration + +[Kafka Streams](https://kafka.apache.org/documentation/streams/) was a great influence in making +Eventy. [Celery](http://www.celeryproject.org/) and [Faust](https://github.com/robinhood/faust) are also worth to be +looked at if you are looking for an opiniated framework easy to get started with. + +However, these frameworks only partially solve all the issues you will have with microservices. And, in our opinion, +these frameworks are not suitable for designing large critical systems. + +They're both opinanated, and therefore cannot be easily integrated in your existing software. You will have to build +your software around the framework, instead of the other way around. They also don't give you the full control on the +way you can use them: you can only use them as a whole, or not at all. + +## What Eventy can do for you + +Eventy implements multiple features, but all of them simply solve two main problems: + +* How to make services communicate with each other +* How to access and persist state + +With Eventy, you can serialize data the way you want. You can use [Avro](https://avro.apache.org/) +, [JSON](https://www.json.org/), [gRPC](https://grpc.io/), or whatever customer serializer you like. + +With Eventy, you can use any system you like as a persistency layer, as long as it supports transactions, if you need +strong processing guarantees. The most obvious choice is to use [Apache Kafka](https://kafka.apache.org/), but +persisting messages over [PostgreSQL](https://www.postgresql.org/) is completely feasable, too. + +Eventy was destined with the mindset of a library of related but independently usable components - and not a framework: +the behaviour is explicit and you're the one in charge: you can design your software your own way. + +This explicit behaviour, albeit requiring more boilerplate, gives you better clarity on what is happening. Recipes and +examples are provided so that you can understand how to use Eventy for most use cases. + +You're free to use any part of Eventy as well. Even if you end up not using the Eventy protocol at all, simply reading +the documentation and understanding the issues that are adressed and how they are adressed can help you to get on the +right path. + +## Main components of Eventy + +* a **well-defined communication protocol** for sending various types of persisted messages, called _Records_: _Events_ + , _Requests_ and _Responses_ +* **persistency of _Records_** that can be stored forever, which lets you keep track of all the changes in your system ( + especially useful for audits and business analytics) +* **queues** so that _Records_ can be processed asynchroneously, and aren't lost even if your system is down or + overloaded +* **strong processing guarantees**: a Record can be designed to be processed _at least once_, _at most once_ and _ + exactly once_ even if your system encounters a process or network failure at any point +* **self-propagating _Contexts_** that in many cases entirely eliminate the need of persisting state +* **partitionned state persistency** so that you no longer have a single point of failure in your system (aka _the + database_) and can scale up as your business grows + +# Contribute + +Install with dev dependencies + +``` +poetry install -E celery -E sanic -E aiohttp -E django -E confluent-kafka -E avro -E requests +``` + +The project uses [poetry](https://python-poetry.org/) + +``` +poetry config pypi-token.pypi my-token +poetry config testpypi-token.pypi my-token +``` + + +%prep +%autosetup -n eventy-3.3.0 + +%build +%py3_build + +%install +%py3_install +install -d -m755 %{buildroot}/%{_pkgdocdir} +if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi +if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi +if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi +if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi +pushd %{buildroot} +if [ -d usr/lib ]; then + find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/lib64 ]; then + find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/bin ]; then + find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/sbin ]; then + find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst +fi +touch doclist.lst +if [ -d usr/share/man ]; then + find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst +fi +popd +mv %{buildroot}/filelist.lst . +mv %{buildroot}/doclist.lst . + +%files -n python3-eventy -f filelist.lst +%dir %{python3_sitelib}/* + +%files help -f doclist.lst +%{_docdir}/* + +%changelog +* Fri May 05 2023 Python_Bot <Python_Bot@openeuler.org> - 3.3.0-1 +- Package Spec generated |
