Feature/config_dict (#28)

* feat: add config_dict and splitted rules capabilities

Signed-off-by: develop-cs <43383361+develop-cs@users.noreply.github.com>

* chore: fix pre-commit warnings

Signed-off-by: develop-cs <43383361+develop-cs@users.noreply.github.com>

* docs: add feature explanations

Signed-off-by: develop-cs <43383361+develop-cs@users.noreply.github.com>

* docs: typos

Signed-off-by: develop-cs <43383361+develop-cs@users.noreply.github.com>

* tests: typos

Signed-off-by: develop-cs <43383361+develop-cs@users.noreply.github.com>

---------

Signed-off-by: develop-cs <43383361+develop-cs@users.noreply.github.com>

Author: develop-cs

.github/ISSUE_TEMPLATE/config.yaml

@@ -1,2 +1,2 @@
 ---
-blank_issues_enabled: false
+blank_issues_enabled: false

.github/PULL_REQUEST_TEMPLATE.md

@@ -11,4 +11,4 @@ If needed, add some details here in order to verify the change (e.g., how to tes
 
 ## Linked issues: (optional)
 - Close ...
-- Close ...
+- Close ...

.github/workflows/ci-cd.yml

@@ -30,7 +30,7 @@ jobs:
           pip install .[dev,test]
       - name: Cache pre-commit hooks
         uses: actions/cache@v4
-        with: 
+        with:
           path: ~/.cache/pre-commit
           key: ${{ runner.os }}-precommit-${{ hashFiles('.pre-commit-config.yaml') }}
       - name: Run pre-commit hooks
@@ -47,7 +47,7 @@ jobs:
       - name: Checkout
         uses: actions/checkout@v4
       - name: Set up Python version
-        uses: actions/setup-python@v5 
+        uses: actions/setup-python@v5
         with:
           python-version: '3.x'
       - name: Build package

.pre-commit-config.yaml

@@ -2,18 +2,44 @@
 default_language_version:
   python: python3
 repos:
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v4.6.0
+    hooks:
+      - id: check-ast
+      - id: check-byte-order-marker
+      - id: check-case-conflict
+      - id: check-docstring-first
+      - id: check-json
+      - id: check-yaml
+        exclude: ^(docs/)
+      - id: debug-statements
+      - id: end-of-file-fixer
+        exclude: ^(docs/)
+      - id: pretty-format-json
+        args: ['--autofix']
+      - id: trailing-whitespace
+        args: ['--markdown-linebreak-ext=md']
+        exclude: ^(docs/)
+      - id: mixed-line-ending
+        args: ['--fix=lf']
+        exclude: ^(docs/)
+      - id: check-added-large-files
+        args: ['--maxkb=500']
+      - id: no-commit-to-branch
+        args: ['--branch', 'main']
   - repo: https://github.com/astral-sh/ruff-pre-commit
-    rev: v0.4.10
+    rev: v0.5.4
     hooks:
       - id: ruff
         args: [ --fix ]
       - id: ruff-format
   - repo: https://github.com/pre-commit/mirrors-mypy
-    rev: 'v1.10.0'
+    rev: v1.11.0
     hooks:
       - id: mypy
         args: [--config-file=pyproject.toml]
         files: src
+        additional_dependencies: [pydantic~=2.0]
   - repo: https://github.com/gitleaks/gitleaks
     rev: v8.18.4
     hooks:
@@ -24,7 +50,7 @@ repos:
       - id: pip-audit
         args: ["--skip-editable"]
   - repo: https://github.com/compilerla/conventional-pre-commit
-    rev: v3.2.0
+    rev: v3.3.0
     hooks:
       - id: conventional-pre-commit
         stages: [commit-msg]

CHANGELOG.md

@@ -4,6 +4,20 @@ All notable changes to this project will be documented in this file.
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.8.0] - July, 2024
+
+### Features
+
+* Add a new parameter `config_dict` in the `RulesEngine`'s constructor. It can be used when you have already loaded the YAML configuration in a dictionary and want to use it straightforward.
+* Split a rule set in two (or more) files (keep the rules organized by their file names [alphabetically sorted]).
+
+### Fixes
+
+* *Simple condition:* an error occurs when the right operand is a uppercase string (e.g., `input.text=="LABEL"`).
+
+### Refactoring
+
+* Function `sanitize_regex()` is converted to an instance method `get_sanitized_id()` of `BaseCondition` class.
 
 ## [0.7.1] - June, 2024
 

CODE_OF_CONDUCT.md

@@ -70,4 +70,4 @@ members of the project's leadership.
 This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
 available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
 
-[homepage]: https://www.contributor-covenant.org
+[homepage]: https://www.contributor-covenant.org

CONTRIBUTING.md

@@ -11,7 +11,7 @@ Explain the layout of your repo.
 
 ## Workflow
 
-The steps below describe how to get a patch into a main development branch (e.g. `master`). 
+The steps below describe how to get a patch into a main development branch (e.g. `master`).
 The steps are exactly the same for everyone involved in the project (be it core team, or first time contributor).
 We follow the standard GitHub [fork & pull](https://help.github.com/articles/using-pull-requests/#fork--pull) approach to pull requests. Just fork the official repo, develop in a branch, and submit a PR!
 
@@ -20,22 +20,22 @@ We follow the standard GitHub [fork & pull](https://help.github.com/articles/usi
 1. [Fork the project](https://github.com/MAIF/arta#fork-destination-box) on GitHub. You'll need to create a feature-branch for your work on your fork, as this way you'll be able to submit a pull request against the mainline *Arta*.
 1. Create a branch on your fork and work on the feature. For example: `git checkout -b feature/awesome-new-feature`
    - Please make sure to follow the general quality guidelines (specified below) when developing your patch.
-   - Please write additional tests covering your feature and adjust existing ones if needed before submitting your pull request. 
+   - Please write additional tests covering your feature and adjust existing ones if needed before submitting your pull request.
 1. Once your feature is complete, prepare the commit with a good commit message, for example: `Adding canary mode support for services #42` (note the reference to the ticket it aimed to resolve).
 1. If it's a new feature, or a change of behaviour, document it on the [Arta docs](https://maif.github.io/arta/home/), remember, an undocumented feature is not a feature.
 1. Now it's finally time to [submit the pull request](https://help.github.com/articles/using-pull-requests)!
     - Please make sure to include a reference to the issue you're solving *in the comment* for the Pull Request, this will cause the PR to be linked properly with the Issue. Examples of good phrases for this are: "Resolves #1234" or "Refs #1234".
 1. Now both committers and interested people will review your code. This process is to ensure the code we merge is of the best possible quality, and that no silly mistakes slip through. You're expected to follow-up these comments by adding new commits to the same branch. The commit messages of those commits can be more loose, for example: `Removed debugging using printline`, as they all will be squashed into one commit before merging into the main branch.
     - The community and team are eager to share, so don't be afraid to ask follow up questions if you didn't understand some comment, or would like clarification on how to continue with a given feature. We're here to help, so feel free to ask and discuss any kind of questions you might have during review!
-1. After the review you should fix the issues as needed (pushing a new commit for new review etc.), iterating until the reviewers give their thumbs up–which is signalled usually by a comment saying `LGTM`, which means "Looks Good To Me". 
+1. After the review you should fix the issues as needed (pushing a new commit for new review etc.), iterating until the reviewers give their thumbs up–which is signalled usually by a comment saying `LGTM`, which means "Looks Good To Me".
 1. If the code change needs to be applied to other branches as well (for example a bugfix needing to be backported to a previous version), one of the team will either ask you to submit a PR with the same commit to the old branch, or do this for you.
 1. Once everything is said and done, your pull request gets merged. You've made it!
 
 The TL;DR; of the above very precise workflow version is:
 
 1. Fork arta
 2. Hack and test on your feature (on a branch)
-3. Document it 
+3. Document it
 4. Submit a PR
 6. Keep polishing it until received thumbs up from the core team
 7. Profit!
@@ -74,4 +74,4 @@ pytest tests/
 
 ## Continuous integration
 
-TODO
+TODO

LICENSE

@@ -174,4 +174,4 @@
       incurred by, or claims asserted against, such Contributor by reason
       of your accepting any such warranty or additional liability.
 
-   END OF TERMS AND CONDITIONS
+   END OF TERMS AND CONDITIONS

NOTICE

@@ -12,4 +12,4 @@ Unless required by applicable law or agreed to in writing, software
 distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
 WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
 License for the specific language governing permissions and limitations under
-the License.
+the License.

README.md

@@ -6,10 +6,11 @@
 </p>
 <p align="center">
   <img src="https://github.com/MAIF/arta/actions/workflows/ci-cd.yml/badge.svg?branch=main" alt="CI">
-  <img src="https://img.shields.io/badge/coverage-97%25-dark_green" alt="Coverage">
+  <img src="https://img.shields.io/badge/coverage-95%25-dark_green" alt="Coverage">
   <img src="https://img.shields.io/pypi/v/arta" alt="Versions">
   <img src="https://img.shields.io/pypi/pyversions/arta" alt="Python">
-  <img src="https://img.shields.io/pypi/dm/arta" alt="Downloads">
+  <img src="https://img.shields.io/pypi/implementation/arta" alt="Python implementation">
+  <img src="https://img.shields.io/pepy/dt/arta" alt="Downloads">
 </p>
 
 ---
@@ -34,7 +35,7 @@ In other words, facilitate rules handling in our python apps.
 
 The need of a python *rules engine* emerged when we were working on a new major release of our internal use of [Melusine](https://github.com/maif/melusine) (i.e., email qualification pipeline with ML capabilities).
 
-We were looking for a python library to *centralize, manage and standardize* all the implemented **business rules** we had but didn't find the perfect fit. 
+We were looking for a python library to *centralize, manage and standardize* all the implemented **business rules** we had but didn't find the perfect fit.
 
 Therefore, we decided to create this package and by extension of the MAIF's values, we planned to share it to the community.
 
@@ -139,4 +140,3 @@ and general hints on how to prepare your pull request. You can also ask for clar
 This project is Open Source and available under the Apache 2 License.
 
 [![Alt MAIF Logo](https://static.maif.fr/resources/img/logo-maif.svg)](https://www.maif.fr/)
-