path: root/python-eventy.spec

%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