summaryrefslogtreecommitdiff
path: root/python-eventy.spec
diff options
context:
space:
mode:
authorCoprDistGit <infra@openeuler.org>2023-05-05 05:31:42 +0000
committerCoprDistGit <infra@openeuler.org>2023-05-05 05:31:42 +0000
commit3733934919adc79052acd57f73f6c74a01108444 (patch)
tree35a4f383329fafe375af0a569d8bf1c9a6a720fd /python-eventy.spec
parent8a7063b8988031acfa3ee9a84b01904e4a83e66e (diff)
automatic import of python-eventyopeneuler20.03
Diffstat (limited to 'python-eventy.spec')
-rw-r--r--python-eventy.spec389
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