🎉 add project files

.dockerignore

@@ -0,0 +1,5 @@
+.venv/
+*.pyc
+__pycache__/
+*.log
+*.sqlite3

.env.example

@@ -0,0 +1 @@
+DEV_MODE=true

.github/workflows/pre-commit.yaml

@@ -0,0 +1,15 @@
+name: pre-commit
+
+on:
+  pull_request:
+  push:
+
+jobs:
+  pre-commit:
+    runs-on: ubuntu-22.04
+    steps:
+      - uses: actions/checkout@v3
+      - uses: actions/setup-python@v4
+        with:
+          python-version: '3.11'
+      - uses: pre-commit/[email protected]

.github/workflows/uni_tests.yaml

@@ -0,0 +1,46 @@
+name: 'Tests'
+
+on:
+  pull_request:
+  push:
+#on:
+#  pull_request:
+#    paths:
+#      - src/ml
+#      - src/evaluation
+
+env:
+  VENV_PATH: "venv_path"
+  AZURE_OPENAI_API_KEY: ${{ secrets.AZURE_OPENAI_API_KEY }}
+  AZURE_OPENAI_API_HOST: ${{ vars.AZURE_OPENAI_API_HOST }}
+  AZURE_OPENAI_API_VERSION: ${{ vars.AZURE_OPENAI_API_VERSION }}
+  AZURE_OPENAI_ENDPOINT: ${{ vars.AZURE_OPENAI_API_BASE }}
+  AZURE_OPENAI_DEPLOYMENT_NAME: ${{ vars.AZURE_OPENAI_DEPLOYMENT_NAME }}
+  AZURE_OPENAI_EMBEDDING_DEPLOYMENT_NAME: ${{ vars.AZURE_OPENAI_EMBEDDING_DEPLOYMENT_NAME }}
+
+jobs:
+  unit-tests:
+    runs-on: ubuntu-22.04
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      - name: "Set up Python"
+        uses: actions/setup-python@v5
+        with:
+          python-version-file: ".python-version"
+
+      # install sudo if needed
+#      - name: Install sudo
+#        run: |
+#          sudo apt update
+#          sudo apt-get update &&  apt-get install -y sudo && apt-get clean && rm -rf /var/lib/apt/lists/*
+
+      - name: Install Python dependencies
+        shell: bash
+        run: |
+          make install-dev
+      - name: Run tests
+        shell: bash
+        run: |
+          make test

.gitignore

@@ -94,12 +94,6 @@ ipython_config.py
 #   install all needed dependencies.
 #Pipfile.lock
 
-# UV
-#   Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
-#   This is especially recommended for binary packages to ensure reproducibility, and is more
-#   commonly ignored for libraries.
-#uv.lock
-
 # poetry
 #   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
 #   This is especially recommended for binary packages to ensure reproducibility, and is more
@@ -165,7 +159,24 @@ cython_debug/
 #  be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
 #  and can be added to the global gitignore or merged into this file.  For a more nuclear
 #  option (not recommended) you can uncomment the following to ignore the entire idea folder.
-#.idea/
+.idea/
+
+# node
+node_modules/
+
+# github actions local
+bin/act
+
+#gitlab ci local
+.gitlab-ci-local/
+
+.cache*
+
+# Windows specific files
+*Zone.Identifier
+
+# project files
+**/*tmp*.py
+**/*temp*.py
 
-# PyPI configuration file
-.pypirc
+!dist/$$.whl

.gitlab-ci.yml

@@ -0,0 +1,28 @@
+default:
+  image: python:3.11
+
+stages:
+  - test-package
+
+variables:
+  VENV_PATH: "$CI_PROJECT_DIR/.venv"  # Define virtual environment path
+  UV_CACHE_DIR: .uv-cache
+cache:
+  key:
+    files: # can't use more than two files in a single cache key.
+      - pyproject.toml
+      - package.json
+
+  paths:
+    - $VENV_PATH  # Cache the virtual environment
+    - $UV_CACHE_DIR
+
+evaluate:
+  stage: test-package  # Reference the correct stage
+  # if you need sudo
+#  before_script:
+#    - apt-get update &&  apt-get install -y sudo && apt-get clean && rm -rf /var/lib/apt/lists/*
+  script:
+    - make install-dev
+    - make test
+    - make cache-uv

.nvmrc

@@ -0,0 +1 @@
+22.8.0

.pre-commit-config.yaml

@@ -0,0 +1,31 @@
+# See https://pre-commit.com for more information
+# See https://pre-commit.com/hooks.html for more hooks
+# ruff is for python files and is used with ruff.toml
+repos:
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v4.3.0
+    hooks:
+      - id: check-added-large-files
+        args: ['--maxkb=3000']
+      - id: check-toml
+      - id: check-yaml
+      - id: check-json
+      - id: detect-private-key
+      - id: end-of-file-fixer
+      #      - id: requirements-txt-fixer
+      #        exclude: ^requirements/.*$
+      - id: trailing-whitespace
+      - id: name-tests-test
+        args: [ --pytest-test-first ]
+
+  - repo: https://github.com/astral-sh/ruff-pre-commit
+    rev: v0.4.2
+    hooks:
+      - id: ruff
+        args: ['--fix']
+      - id: ruff-format
+
+  -   repo: https://github.com/Yelp/detect-secrets
+      rev: v1.5.0
+      hooks:
+        -   id: detect-secrets

.python-version

@@ -0,0 +1 @@
+3.11

CONTRIBUTING.md

@@ -0,0 +1,102 @@
+# Contributing to this project
+
+First off, thanks for taking the time to contribute! ❤️
+
+## 1. Code of Conduct
+
+This project and everyone participating in it is governed by the [Code of Conduct](CODE_OF_CONDUCT.md).
+By participating, you are expected to uphold this code. Please report unacceptable behavior.
+
+
+## 2. Team members:
+- Amine Djeghri
+
+## 3. Best practices 💡
+- Docstring your functions and classes, it is even more important as it is used to generate the documentation with Mkdocs
+- If you use an IDE (like pycharm), define src the "source" folder and test the "test" folder so your IDE can help you auto import files
+- Use the `make` commands to run your code, it is easier and faster than writing the full command (and check the Makefile for all available commands 😉)
+    - Run [Use the pre-commit hooks](https://pre-commit.com/) to ensure your code is formatted correctly and is of good quality
+    - [UV](https://docs.astral.sh/uv/ ) is powerful (multi-thread, package graph solving, rust backend, etc.) use it as much as you can.
+    - If you have a lot of data, use Polars for faster and more efficient dataframe processing.
+    - If you have CPU intensive tasks, use multiprocessing with python's pool map.
+
+- Exceptions:
+    - Always log the exceptions and errors (use loguru) and then raise them
+    ```py
+        except Exception as e:
+          logger.error(e)  # Log the original error  with a personalized message or with e (only the message will be logged)
+          raise e # All the stack trace will be logged
+    ```
+    - Sometimes, you don't need to raise the exception (in a loop for example) to not interrupt the execution.
+    - Use if else instead of catching and raising the exception when possible (log and raise also)
+      ```py
+          if not os.path.exists(file_path):
+              logger.error(f"File not found: {file_path}. The current directory is: {os.getcwd()}")
+              raise FileNotFoundError(f"The file {file_path} does not exist.")
+      ```
+## 4. How to contribute
+### 4.1 File structure (🌳 Tree)
+Check the readme file.
+
+### 4.2 Steps for Installation (Contributors and maintainers)
+
+- The first step is [to install, read and test the project as a user](README.md#-steps-for-installation-users)
+- Then you can either [develop in a container](#22-or-develop-in-a-container) or [develop locally](#21-local-development)
+
+#### a. Local development
+- Requires Debian (Ubuntu 22.04) or MacOS.
+- Python will be installed using uv.
+- git clone the repository
+- Install the package in editable mode with one of the following commands :
+  - ``make install-dev`` the recommended way. it uses uv and will automatically create a .venv folder inside the project and install the dependencies
+  - or ``uv pip install -e .`` will install the package in your selected environment (venv, or conda or ...)
+  - (note recommended)  or ``pip install -e .`` if you don't have uv (we strongly recommend starting using uv)
+
+- run ``make pre-commit install`` to install pre-commit hooks
+- To install the GitHub actions locally, run ``make install-act``
+- To install the gitlab ci locally, run ``make install-ci``
+
+#### b. or Develop in a container
+- If you have a .venv folder locally, you need to delete it, otherwise it will create a conflict since the project is mounted in the container.
+- You can run a docker image containing the project with ``make docker-prod`` (or ``make docker-dev`` if you want the project to be mounted in the container).
+- A venv is created inside the container and the dependencies are installed.
+
+###  4.3. Run the test to see if everything is working
+- Create a ``.env`` file *(take a look at the ``.env.example`` file)*:
+- Test the package with :
+    - ``make test-installation`` Will print a hello message
+    - ``make test`` will run all the tests (requires .env file)
+
+### 4.4. Pushing your work
+- Before you start working on an issue, please comment on (or create) the issue and wait for it to be assigned to you. If
+  someone has already been assigned but didn't have the time to work on it lately, please communicate with them and ask if
+  they're still working on it. This is to avoid multiple people working on the same issue.
+  Once you have been assigned an issue, you can start working on it. When you are ready to submit your changes, open a
+  pull request. For a detailed pull request tutorial, see this guide.
+
+1. Create a branch from the dev branch and respect the naming convention: `feature/your-feature-name`
+   or `bugfix/your-bug-name`.
+2. Before commiting your code :
+
+   - Run ``make test`` to run the tests
+   - Run ``make pre-commit`` to check the code style & linting.
+   - Run ``make serve-docs`` to update the documentation
+   - (optional) Commit Messages: This project uses [Gitmoji](https://gitmoji.dev/) for commit messages. It helps to
+     understand the purpose of the commit through emojis. For example, a commit message with a bug fix can be prefixed with
+     🐛. There are also [Emojis in GitHub](https://github.com/ikatyang/emoji-cheat-sheet/blob/master/README.md)
+   - Manually, merge dev branch into your branch to solve and avoid any conflicts. Merging strategy: merge : dev →
+     your_branch
+   - After merging, run ``make test`` and ``make pre-commit`` again to ensure that the tests are still passing.
+   - Update the version in ``pyproject.toml`` file
+   - if your project is a python package, run ``make build-pacakge`` to build the package and create the wheel in the `dist` folder
+3. Run CI/CD Locally: Depending on the platform you use:
+   - GitHub Actions: run `make install-act` then `make act` for GitHub Actions
+   - GitLab CI: run `make install-gitlab-ci-local` then `make gitlab-ci-local` for GitLab CI.
+4. Create a pull request. If the GitHub actions pass, the PR will be accepted and merged to dev.
+
+### 4.5. (For repository maintainers) Merging strategies & GitHub actions guidelines**
+
+- Once the dev branch is tested, the pipeline is green, and the PR has been accepted, you can merge with a 'merge'
+  strategy.
+- DEV → MAIN: Then, you should create a merge from dev to main with Squash strategy.
+- MAIN → RELEASE: The status of the ticket will change then to 'done.'