Populate repository

Author: mrDzurb

.gitignore

@@ -0,0 +1,163 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+env/
+build/
+docs/build/
+docs/docs_html/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+ads_latest.zip
+
+# 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/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+.hypothesis/
+.pytest_cache
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+docs/build/
+docs/dask-worker-space/
+
+# PyBuilder
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# pyenv
+.python-version
+
+# celery beat schedule file
+celerybeat-schedule
+
+# SageMath parsed files
+*.sage.py
+
+# dotenv
+.env
+
+# virtualenv
+.venv
+venv/
+ENV/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+
+### Linux ###
+*~
+
+# IntelliJ/Pycharm settings
+*.iml
+.idea
+.vscode/
+
+# Mac OS metadata
+.DS_Store
+.AppleDouble
+.LSOverride
+
+# dask related
+dask-worker-space
+
+#sqllite databases
+*.db
+
+Untitled*.ipynb
+*.lock
+*.dirlock
+
+
+# test results
+testresults.xml
+
+
+
+# html reports of covered code by pytests and
+# execution data collected by coverage.py
+*coverage_html_report*
+.coverage
+.coverage*
+**.sqlite
+
+extensions/**/node_modules/
+extensions/**/*.tgz
+logs/
+**/node_modules
+
+# side-effects of running notebooks
+**/.mlx_static/**
+
+# vim
+*.swp
+
+*.whl
+.env
+local_workarea
+mlruns
+tmp
+conda
+
+docs/build

.pre-commit-config.yaml

@@ -0,0 +1,25 @@
+repos:
+-   repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v4.4.0
+    hooks:
+    -   id: check-ast
+    -   id: check-docstring-first
+        exclude: ^tests/
+    -   id: check-json
+    -   id: check-merge-conflict
+    -   id: check-yaml
+        args: ['--allow-multiple-documents']
+    -   id: detect-private-key
+    -   id: end-of-file-fixer
+    -   id: pretty-format-json
+        args: ['--autofix']
+    -   id: trailing-whitespace
+-   repo: https://github.com/psf/black
+    rev: 22.12.0
+    hooks:
+    -   id: black
+-   repo: https://github.com/pre-commit/pygrep-hooks
+    rev: v1.9.0
+    hooks:
+    -   id: rst-backticks
+    -   id: rst-inline-touching-normal

CONTRIBUTING.md

@@ -1,21 +1,19 @@
-*Detailed instructions on how to contribute to the project, if applicable. Must include section about Oracle Contributor Agreement with link and instructions*
-
 # Contributing to this repository
 
 We welcome your contributions! There are multiple ways to contribute.
 
 ## Opening issues
 
-For bugs or enhancement requests, please file a GitHub issue unless it's
-security related. When filing a bug remember that the better written the bug is,
+For bugs or enhancement requests, file a GitHub issue unless it's
+security related. When filing a bug, remember that the better written the bug is,
 the more likely it is to be fixed. If you think you've found a security
-vulnerability, do not raise a GitHub issue and follow the instructions in our
+vulnerability, don't raise a GitHub issue and follow the instructions in our
 [security policy](./SECURITY.md).
 
 ## Contributing code
 
-We welcome your code contributions. Before submitting code via a pull request,
-you will need to have signed the [Oracle Contributor Agreement][OCA] (OCA) and
+We welcome your code contributions. Before submitting code using a pull request,
+you must sign the [Oracle Contributor Agreement](https://oca.opensource.oracle.com) (OCA) and
 your commits need to include the following line using the name and e-mail
 address you used to sign the OCA:
 
@@ -24,34 +22,32 @@ Signed-off-by: Your Name <you@example.org>
 ```
 
 This can be automatically added to pull requests by committing with `--sign-off`
-or `-s`, e.g.
+or `-s`, for example:
 
 ```text
 git commit --signoff
 ```
 
 Only pull requests from committers that can be verified as having signed the OCA
-can be accepted.
+are accepted.
 
 ## Pull request process
 
 1. Ensure there is an issue created to track and discuss the fix or enhancement
    you intend to submit.
-1. Fork this repository.
-1. Create a branch in your fork to implement the changes. We recommend using
-   the issue number as part of your branch name, e.g. `1234-fixes`.
-1. Ensure that any documentation is updated with the changes that are required
+2. Fork this repository.
+3. Create a branch in your fork to implement the changes. We recommend using
+   the issue number as part of your branch name, for example `1234-fixes`.
+4. Ensure that any documentation is updated with the changes that are required
    by your change.
-1. Ensure that any samples are updated if the base image has been changed.
-1. Submit the pull request. *Do not leave the pull request blank*. Explain exactly
-   what your changes are meant to do and provide simple steps on how to validate.
+5. Ensure that any samples are updated if the base image has been changed.
+6. Submit the pull request. *Don't leave the pull request blank*. Explain exactly
+   what your changes are meant to do and provide simple steps about how to validate
    your changes. Ensure that you reference the issue you created as well.
-1. We will assign the pull request to 2-3 people for review before it is merged.
+7. We assign the pull request to 2-3 people for review before it is merged.
 
 ## Code of conduct
 
 Follow the [Golden Rule](https://en.wikipedia.org/wiki/Golden_Rule). If you'd
-like more specific guidelines, see the [Contributor Covenant Code of Conduct][COC].
-
-[OCA]: https://oca.opensource.oracle.com
-[COC]: https://www.contributor-covenant.org/version/1/4/code-of-conduct/
+like more specific guidelines, see the
+[Contributor Covenant Code of Conduct](https://www.contributor-covenant.org/version/1/4/code-of-conduct/).

ISSUE_POLICY.md

@@ -0,0 +1,85 @@
+# Issue Policy
+
+The OCI MLflow Issue Policy outlines the categories of OCI MLflow GitHub issues and discusses the guidelines and processes associated with each type of issue.
+
+Before filing an issue, make sure to [search for related issues](https://github.com/oracle/oci-mlflow/issues) and check if they address the same problem you're encountering.
+
+## Issue Categories
+
+Our policy states that GitHub issues fall into the following categories:
+
+1. Feature Requests
+2. Bug Reports
+3. Documentation Fixes
+4. Installation Issues
+
+Each category has its own GitHub issue template. Please refrain from deleting the issue template unless you are certain that your issue does not fit within its scope.
+
+### Feature Requests
+
+#### Guidelines
+
+To increase the likelihood of having a feature request accepted, please ensure that:
+
+- The request has a minimal scope (note that it's easier to add additional functionality later than to remove functionality).
+- The request has a significant impact on users and provides value that justifies the maintenance efforts required to support the feature in the future.
+
+#### Lifecycle
+
+Feature requests typically go through the following stages:
+
+1. Submit a feature request GitHub Issue, providing a brief overview of the proposal and its motivation. If possible, include an implementation overview as well.
+2. The issue will be triaged to determine if more information is needed from the author, assign a priority, and route the request to the appropriate committers.
+3. Discuss the feature request with a committer who will provide input on the implementation overview or request a more detailed design if necessary.
+4. Once there is agreement on the feature request and its implementation, an implementation owner will be assigned.
+5. The implementation owner will start developing the feature and ultimately submit associated pull requests to the OCI MLflow Repository.
+
+### Bug Reports
+
+#### Guidelines
+
+To ensure that maintainers can effectively assist with any reported bugs, please follow these guidelines:
+
+- Fill out the bug report template completely, providing appropriate levels of detail, especially in the "Code to reproduce issue" section.
+- Verify that the bug you are reporting meets one of the following criteria:
+  - It is a regression where a recent release of OCI MLflow no longer supports an operation that was supported in an earlier release.
+  - A documented feature or functionality does not work as intended when executing a provided example from the documentation.
+  - Any raised exception is directly from OCI MLflow and not the result of an underlying package's exception.
+- Make an effort to diagnose and troubleshoot the issue before filing the report.
+- Ensure that the environment in which you encountered the bug is supported as defined in the documentation.
+- Validate that OCI MLflow supports the functionality you are experiencing issues with. Remember that the absence of a feature does not constitute a bug.
+- Read the documentation for the feature related to the issue you are reporting. If you are certain that you are following the documented guidelines, please file a bug report.
+
+#### Lifecycle
+
+Bug reports typically go through the following stages:
+
+1. Submit a bug report GitHub Issue, providing a high-level description of the bug and all the necessary information to reproduce it.
+2. The bug report will be triaged to determine if more information is required from the author, assign a priority, and route the issue to the appropriate committers.
+3. An OCI MLflow committer will reproduce the bug and provide feedback on how to implement a fix.
+4. Once an approach has been agreed upon, an owner for the fix will be assigned. For severe bugs, OCI MLflow committers may choose to take ownership to ensure a timely resolution.
+5. The fix owner will start implementing the solution and ultimately submit associated pull requests.
+
+### Documentation Fixes
+
+#### Lifecycle
+
+Documentation issues typically go through the following stages:
+
+1. Submit a documentation GitHub Issue, describing the issue and indicating its location(s) in the OCI MLflow documentation.
+2. The issue will be triaged to determine if more information is needed from the author, assign a priority, and route the request to the appropriate committers.
+3. An OCI MLflow committer will confirm the documentation issue and provide feedback on how to implement a fix.
+4. Once an approach has been agreed upon, an owner for the fix will be assigned. For severe documentation issues, OCI MLflow committers may choose to take ownership to ensure a timely resolution.
+5. The fix owner will start implementing the solution and ultimately submit associated pull requests.
+
+### Installation Issues
+
+#### Lifecycle
+
+Installation issues typically go through the following stages:
+
+1. Submit an installation GitHub Issue, describing the issue and indicating the platforms it affects.
+2. The issue will be triaged to determine if more information is needed from the author, assign a priority, and route the issue to the appropriate committers.
+3. An OCI MLflow committer will confirm the installation issue and provide feedback on how to implement a fix.
+4. Once an approach has been agreed upon, an owner for the fix will be assigned. For severe installation issues, OCI MLflow committers may choose to take ownership to ensure a timely resolution.
+5. The fix owner will start implementing the solution and ultimately submit associated pull requests.

LICENSE.txt

@@ -1,4 +1,4 @@
-Copyright (c) 2023 Oracle and/or its affiliates.
+Copyright (c) 2023 Oracle and/or its affiliates. All rights reserved.
 
 The Universal Permissive License (UPL), Version 1.0
 

MANIFEST.in

@@ -0,0 +1,4 @@
+include LICENSE.txt
+include THIRD_PARTY_LICENSES.txt
+include oci_mlflow/version.json
+include oci_mlflow/templates/*.jinja2

Makefile

@@ -0,0 +1,28 @@
+include .env
+
+.PHONY: build clean deploy
+
+TAG:=latest
+IMAGE_NAME:=oci-mlflow
+CONTAINERDIR:=container-image
+RND:=1
+
+clean:
+	@rm -rf dist build oci_mlflow.egg-info
+
+build: clean
+	@python setup.py bdist_wheel
+
+wheel: build tmp-copy-whl
+
+build-image:
+	docker build --network host --build-arg RND=$(RND) -t $(IMAGE_NAME):$(TAG) -f container-image/Dockerfile .
+
+launch: build-image
+	@docker run --rm -it --net host -v ~/.oci:/root/.oci --env-file .env --name oci-mlflow $(IMAGE_NAME):$(TAG)
+
+launch-shell:
+	@docker run --rm -it --net host -v ~/.oci:/root/.oci  --env-file .env --entrypoint bash --name oci-mlflow-shell $(IMAGE_NAME):$(TAG)
+
+launch-shell-remote:
+	@docker run --rm -it --net host --env-file .env --entrypoint bash --name oci-mlflow-shell $(IMAGE_NAME):$(TAG)