Initialise SDK

.github/CODEOWNERS

@@ -0,0 +1,4 @@
+# This is a comment.
+# Read more here https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners#codeowners-file-location
+
+* @SHARANTANGEDA

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,45 @@
+## What does this PR address?
+
+
+Thanks for sending a pull request!
+
+<!--
+We really appreciate your sincere efforts There are still a few things to run through
+
+Please fill out the blanks below before requesting a code review.
+
+Name your Pull Request with one of the following prefixes, e.g. "feat: add support for PyTorch", to indicate the type of changes proposed. This is based on the [Conventional Commits specification](https://www.conventionalcommits.org/en/v1.0.0/#summary).
+  - feat: (new feature for the user, not a new feature for build script)
+  - fix: (bug fix for the user, not a fix to a build script)
+  - docs: (changes to the documentation)
+  - style: (formatting, missing semicolons, etc; no production code change)
+  - refactor: (refactoring production code, eg. renaming a variable)
+  - perf: (code changes that improve performance)
+  - test: (adding missing tests, refactoring tests; no production code change)
+  - chore: (updating grunt tasks etc; no production code change)
+  - build: (changes that affect the build system or external dependencies)
+  - ci: (changes to configuration files and scripts)
+  - revert: (reverts a previous commit)
+
+Describe your changes in detail. Attach screenshots here if appropriate.
+
+
+Once you're done with this, someone from xpuls-labs core team or extended team will help review your PR. If no one has reviewed your PR after a week have passed, don't hesitate to post a new comment and ping @SHARANTANGEDA. Notifications sometimes might get lost 🥲.
+-->
+
+<!-- Remove if not applicable -->
+
+Fixes #(issue)
+
+## Before submitting:
+
+<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
+<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
+<!--- If you plan to update documentation or tests in follow-up, please note -->
+
+- [ ] Does the Pull Request follow [Conventional Commits specification](https://www.conventionalcommits.org/en/v1.0.0/#summary) naming? Here are [GitHub's
+      guide](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request) on how to create a pull request.
+- [ ] Does the code follow mlmonitor's code style, `pre-commit run -a` script has passed ?
+- [ ] Did your changes require updates to the documentation? Have you updated
+      those accordingly?
+- [ ] Did you write tests to cover your changes?

.github/workflows/deploy.yaml

@@ -0,0 +1,27 @@
+name: pypi-release
+on:
+  push:
+    tags:
+      - v*
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - name: Setup Python
+        uses: actions/setup-python@v4
+        with:
+          python-version: '3.11'
+      - name: Install dependencies
+        run: python -m pip install --upgrade build
+      - name: Build
+        run: python -m build
+      - name: Publish to PyPI
+        uses: pypa/gh-action-pypi-publish@release/v1
+        with:
+          password: ${{ secrets.PYPI_PUBLIC_TOKEN }}
+      - name: Archive
+        uses: actions/upload-artifact@v3
+        with:
+          name: dist
+          path: dist/*

.gitignore

@@ -0,0 +1,171 @@
+**/__pycache__
+*.egg*
+build
+.idea
+/dist/*
+.DS*
+**/venv
+**/dist
+.ipynb_checkpoints/**
+.vscode/**
+
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#  Usually these files are written by a python script from a template
+#  before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py,cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+#Pipfile.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
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+#poetry.lock
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#pdm.lock
+#   pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it
+#   in version control.
+#   https://pdm.fming.dev/#use-with-ide
+.pdm.toml
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#  JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#  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/