| Name | oteapi-core JSON |
| Version |
0.6.1
JSON |
| download |
| home_page | |
| Summary | Open Translation Environment (OTE) API. |
| upload_time | 2023-11-14 00:23:07 |
| maintainer | |
| docs_url | None |
| author | |
| requires_python | >=3.9 |
| license | |
| keywords |
ote
ote-api
|
| VCS |
 |
| bugtrack_url |
|
| requirements |
No requirements were recorded.
|
| Travis-CI |
No Travis.
|
| coveralls test coverage |
No coveralls.
|
# Open Translation Environment (OTE) API Core
> Framework for accessing data resources, mapping data models, describing the data to ontologies and perform data transformations
[](https://pypi.org/project/oteapi-core)
[](https://pypi.org/project/oteapi-core)
[](https://app.codecov.io/gh/EMMC-ASBL/oteapi-core)
[](https://github.com/EMMC-ASBL/oteapi-core/actions/workflows/ci_tests.yml?query=branch%3Amaster)
[](https://github.com/EMMC-ASBL/oteapi-core/pulse)
[](https://github.com/EMMC-ASBL/oteapi-core/graphs/commit-activity)
[](https://zenodo.org/badge/latestdoi/447260507)
We highly recommend reading this page in [the official documentation](https://emmc-asbl.github.io/oteapi-core).
**Important**: As of **v0.6.0**, OTEAPI Core is no longer compatible with pydantic v1, but only with pydantic v2.
For more information about migrating your plugin repository to pydantic v2, see the [pydantic documentation's migration guide](https://docs.pydantic.dev/latest/migration/).
Until the end of 2023, pydantic v1 will still be supported with security updates, but no new features will be added.
To keep using pydantic v1, one should use the **v0.5.x** versions of OTEAPI Core.
## About OTEAPI Core
OTEAPI Core provides the core functionality of OTEAPI, which stands for the *Open Translation Environment API*.
It uses the [strategy](https://en.wikipedia.org/wiki/Strategy_pattern) software design pattern to implement a simple and easy to extend access to a large range of data resources.
Semantic interoperability is supported via mapping of data models describing the data to ontologies.
A set of strategy interfaces that can be considered abstract classes for the implementation of strategies, and data models used in their configuration, are provided.
This repo also contains implementations for several standard strategies, e.g., downloading files, parsing Excel documents.
Transformations, mainly intended to transform data between representations, are also supported, but transformations can also be used for running simulations in a simple workflow.
OTEAPI Core includes:
* A set of standard strategies;
* A plugin system for loading the standard strategies, as well as third party strategies;
* Data models for configuring the strategies;
* A Python library, through which the data can be accessed; and
* An efficient data cache module that avoids downloading the same content several times.
## Types of strategies
### Download strategy
Download strategy patterns use a given protocol to download content into the data cache.
They are configured with the `ResourceConfig` data model, using the scheme of the `downloadUrl` field for strategy selection.
The `configuration` field can be used to configure how the downloaded content is stored in the cache using the `DownloadConfig` data model.
Standard downloaded strategies: *file*, *https*, *http*, *sftp*, *ftp*
### Parse strategy
Parse strategy patterns convert content from the data cache to a Python dict.
Like download strategies, they are configured with the `ResourceConfig` data model, using the `mediaType` field for strategy selection.
Additional strategy-specific configurations can be provided via the `configuration` field.
Standard parse strategies: *application/json*, *image/jpg*, *image/jpeg*, *image/jp2*, *image/png*, *image/gif*, *image/tiff*, *image/eps*, *application/vnd.openxmlformats-officedocument.spreadsheetml.sheet*, *application/vnd.sqlite3*
### Resource strategy
Resource strategy patterns can retrieve/upload data to external data services.
They are configured with the `ResourceConfig` data model, using the scheme of the `accessUrl` and `accessService` fields.
The scheme of the `accessUrl` is used for strategy selection.
### Mapping strategy
Strategies for mapping fields/properties in data models to ontological concepts.
### Filter strategy
Filter strategies can update the configuration of other strategies.
They can also update values in the data cache.
Standard filter strategies: *filter/crop*, *filter/sql*
### Function strategy
Function strategies are synchronous transformations that (normally) run directly on the server hosting the OTE service.
### Transformation strategy
Transformation strategies are a special form of a function strategy intended for long-running transformations.
In this sense, they represent asynchronous functions running in the background or on external resources.
Standard transformation strategies: *celery/remote*
The transformation strategy has consolidated the execution of the
transformation with the `get()` method to unify the strategy interfaces.
`get()` is intended to start an asynchronous process and return a
*task_id* which can be queried using the `status()` method (outside of a pipeline).
## Entry points for plugins
The way strategies are registered and found is through [entry points](https://packaging.python.org/en/latest/specifications/entry-points/).
Special group names allow understanding the strategy type and the entry point values allow understanding of what kind of strategy a specific class implements.
A full overview of recognized entry point group names can be seen in [Table of entry point strategies](#table-of-entry-point-strategies).
### Defining entry points
In the following examples, let's imagine we have a package importable in Python through `my_plugin` and contains two download strategies and a single parse strategy:
1. A peer-2-peer download strategy, implemented in a class named `Peer2PeerDownload` importable from `my_plugin.strategies.download.peer_2_peer`.
2. A MongoDB download strategy, implemented in a class named `MongoRetrieve` importable from `my_plugin.strategies.mongo`.
3. A MongoDB parse strategy, implemented in a class named `MongoParse` importable from `my_plugin.strategies.mongo`.
There are now various different ways to let the Python environment know of these strategies through entry points.
#### `setup.py`
In the package's `setup.py` file, one can specify entry points.
Here, an example snippet is shown using [setuptools](https://setuptools.pypa.io/):
```python
# setup.py
from setuptools import setup
setup(
# ...,
entry_points={
"oteapi.download": [
"my_plugin.p2p = my_plugin.strategies.download.peer_2_peer:Peer2PeerDownload",
"my_plugin.mongo = my_plugin.strategies.mongo:MongoRetrieve",
],
"oteapi.parse": [
"my_plugin.application/vnd.mongo+json = my_plugin.strategies.mongo:MongoParse",
]
},
)
```
#### YAML/JSON custom files
Use custom files that are later parsed and used in a `setup.py` file.
```yaml
entry_points:
oteapi.download:
- "my_plugin.p2p = my_plugin.strategies.download.peer_2_peer:Peer2PeerDownload"
- "my_plugin.mongo = my_plugin.strategies.mongo:MongoRetrieve"
oteapi.parse:
- "my_plugin.application/vnd.mongo+json = my_plugin.strategies.mongo:MongoParse"
```
```json
{
"entry_points": {
"oteapi.download": [
"my_plugin.p2p = my_plugin.strategies.download.peer_2_peer:Peer2PeerDownload",
"my_plugin.mongo = my_plugin.strategies.mongo:MongoRetrieve"
],
"oteapi.parse": [
"my_plugin.application/vnd.mongo+json = my_plugin.strategies.mongo:MongoParse"
]
}
}
```
#### `setup.cfg`/`pyproject.toml`
A more modern approach is to use `setup.cfg` or `pyproject.toml`.
```ini
[options.entry_points]
oteapi.download =
my_plugin.p2p = my_plugin.strategies.download.peer_2_peer:Peer2PeerDownload
my_plugin.mongo = my_plugin.strategies.mongo:MongoRetrieve
oteapi.parse =
my_plugin.application/vnd.mongo+json = my_plugin.strategies.mongo:MongoParse
```
### Syntax and semantics
As seen above, there are a few different syntactical flavors of how to list the entry points.
However, the "value" stays the same throughout.
#### General Python entry points
The general syntax for entry points is based on `ini` files and parsed using the built-in `configparser` module described [here](https://docs.python.org/3/library/configparser.html#module-configparser).
Specifically for entry points the nomenclature is the following:
```ini
[options.entry_points]
GROUP =
NAME = VALUE
```
The `VALUE` is then further split into: `PACKAGE.MODULE:OBJECT.ATTRIBUTE [EXTRA1, EXTRA2]`.
#### OTEAPI strategy entry points
From the general syntax outlined above, OTEAPI Core then implements rules and requirements regarding the syntax for strategies.
1. A class *MUST* be specified (as an `OBJECT`).
2. The `NAME` *MUST* consist of exactly two parts: `PACKAGE` and strategy type value in the form of `PACKAGE.STRATEGY_TYPE_VALUE`.
3. The `GROUP` *MUST* be a valid OTEAPI entry point group, see [Table of entry point strategies](#table-of-entry-point-strategies) for a full list of valid OTEAPI entry point group values.
To understand what the strategy type value should be, see [Table of entry point strategies](#table-of-entry-point-strategies).
### Table of entry point strategies
| Strategy Type Name | Strategy Type Value | Entry Point Group | Documentation Reference |
|:---:|:---:|:---:|:--- |
| Download | [`scheme`](oteapi/models/resourceconfig.py) | `oteapi.download` | [Download strategy](#download-strategy) |
| Filter | [`filterType`](oteapi/models/filterconfig.py) | `oteapi.filter` | [Filter strategy](#filter-strategy) |
| Function | [`functionType`](oteapi/models/functionconfig.py) | `oteapi.function` | [Function strategy](#function-strategy) |
| Mapping | [`mappingType`](oteapi/models/mappingconfig.py) | `oteapi.mapping` | [Mapping strategy](#mapping-strategy) |
| Parse | [`mediaType`](oteapi/models/resourceconfig.py) | `oteapi.parse` | [Parse strategy](#parse-strategy) |
| Resource | [`accessService`](oteapi/models/resourceconfig.py) | `oteapi.resource` | [Resource strategy](#resource-strategy) |
| Transformation | [`transformationType`](oteapi/models/transformationconfig.py) | `oteapi.transformation` | [Transformation strategy](#transformation-strategy) |
## Other OTEAPI-related repositories
* [OTEAPI Services](https://github.com/EMMC-ASBL/oteapi-services) - a RESTful interface to OTEAPI Core
* [OTELib](https://github.com/EMMC-ASBL/otelib) - a Python interface to OTEAPI Services
* [OTEAPI Plugin Template](https://github.com/EMMC-ASBL/oteapi-plugin-template) - a [cookiecutter](https://cookiecutter.readthedocs.io/) template for OTEAPI Plugins
## Installation
OTEAPI Core can be installed with:
```shell
pip install oteapi-core
```
### For developers
If you want to install OTEAPI Core to have a developer environment, please clone down the repository from GitHub and install:
```shell
git clone https://github.com/EMMC-ASBL/oteapi-core /path/to/oteapi-core
pip install -U --upgrade-strategy=eager -e /path/to/oteapi-core[dev]
```
Note, `/path/to/oteapi-core` can be left out of the first line, but then it must be updated in the second line, either to `./oteapi-core`/`oteapi-core` or `.` if you `cd` into the generated folder wherein the repository has been cloned.
The `--upgrade-strategy=eager` part can be left out.
We recommend installing within a dedicated virtual environment.
To test the installation, you can run:
```shell
cd /path/to/oteapi-core
pytest
```
If you run into issues at this stage, please [open an issue](https://github.com/EMMC-ASBL/oteapi-core/issues/new).
## Using Docker with PostgreSQL
Docker is an effective tool for creating portable, isolated environments for your applications.
Here's an example of setting up a PostgreSQL instance using Docker:
1. **Create a Docker volume**: Docker volumes enable data to persist across uses of Docker containers.
In this context, we create a volume called pgdata to store database data.
```shell
docker volume create pgdata
```
2. **Start a Docker container**: Use the `docker run` command to initiate a new Docker container using the postgres image.
Here's a breakdown of the options used in the command:
`-d`: Runs the container in the background (detached mode), freeing up your terminal.
`--name postgres`: Names the container postgres, allowing it to be referenced in future Docker commands.
`-e POSTGRES_PASSWORD=postgres`: Sets an environment variable in the container to specify the PostgreSQL database password as postgres.
`-p 5432:5432`: Maps port 5432 of the container to port 5432 of the host machine, letting applications on the host connect to the PostgreSQL database in the container.
`-v pgdata:/var/lib/postgresql/data`: Mounts the pgdata volume at the path /var/lib/postgresql/data inside the container, which is the storage location for PostgreSQL data files.
`--restart always`: Ensures the container restarts whenever it stops, unless it is manually stopped, in which case it only restarts when the Docker daemon starts, usually on system boot.
```shell
docker run -d --name postgres \
-e POSTGRES_PASSWORD=postgres \
-p 5432:5432 \
-v pgdata:/var/lib/postgresql/data \
--restart always postgres
```
## License
OTEAPI Core is released under the [MIT license](LICENSE) with copyright © SINTEF.
## Acknowledgment
OTEAPI Core has been supported by the following projects:
* **OntoTrans** (2020-2024) that receives funding from the European Union’s Horizon 2020 Research and Innovation Programme, under Grant Agreement no. 862136.
* **VIPCOAT** (2021-2025) receives funding from the European Union’s Horizon 2020 Research and Innovation Programme - DT-NMBP-11-2020 Open Innovation Platform for Materials Modelling, under Grant Agreement no: 952903.
* **OpenModel** (2021-2025) receives funding from the European Union’s Horizon 2020 Research and Innovation Programme - DT-NMBP-11-2020 Open Innovation Platform for Materials Modelling, under Grant Agreement no: 953167.
Raw data
{
"_id": null,
"home_page": "",
"name": "oteapi-core",
"maintainer": "",
"docs_url": null,
"requires_python": ">=3.9",
"maintainer_email": "",
"keywords": "OTE,OTE-API",
"author": "",
"author_email": "SINTEF <Team4.0@SINTEF.no>",
"download_url": "https://files.pythonhosted.org/packages/fe/cd/97ddc69a6e0a7a56f5624b819ef8e98619048b8a833a6a725a2b462a9756/oteapi_core-0.6.1.tar.gz",
"platform": null,
"description": "# Open Translation Environment (OTE) API Core\n\n> Framework for accessing data resources, mapping data models, describing the data to ontologies and perform data transformations\n\n[](https://pypi.org/project/oteapi-core)\n[](https://pypi.org/project/oteapi-core)\n[](https://app.codecov.io/gh/EMMC-ASBL/oteapi-core)\n[](https://github.com/EMMC-ASBL/oteapi-core/actions/workflows/ci_tests.yml?query=branch%3Amaster)\n[](https://github.com/EMMC-ASBL/oteapi-core/pulse)\n[](https://github.com/EMMC-ASBL/oteapi-core/graphs/commit-activity)\n[](https://zenodo.org/badge/latestdoi/447260507)\n\nWe highly recommend reading this page in [the official documentation](https://emmc-asbl.github.io/oteapi-core).\n\n**Important**: As of **v0.6.0**, OTEAPI Core is no longer compatible with pydantic v1, but only with pydantic v2.\nFor more information about migrating your plugin repository to pydantic v2, see the [pydantic documentation's migration guide](https://docs.pydantic.dev/latest/migration/). \nUntil the end of 2023, pydantic v1 will still be supported with security updates, but no new features will be added.\nTo keep using pydantic v1, one should use the **v0.5.x** versions of OTEAPI Core.\n\n## About OTEAPI Core\n\nOTEAPI Core provides the core functionality of OTEAPI, which stands for the *Open Translation Environment API*.\n\nIt uses the [strategy](https://en.wikipedia.org/wiki/Strategy_pattern) software design pattern to implement a simple and easy to extend access to a large range of data resources.\nSemantic interoperability is supported via mapping of data models describing the data to ontologies.\nA set of strategy interfaces that can be considered abstract classes for the implementation of strategies, and data models used in their configuration, are provided.\nThis repo also contains implementations for several standard strategies, e.g., downloading files, parsing Excel documents.\nTransformations, mainly intended to transform data between representations, are also supported, but transformations can also be used for running simulations in a simple workflow.\n\nOTEAPI Core includes:\n\n* A set of standard strategies;\n* A plugin system for loading the standard strategies, as well as third party strategies;\n* Data models for configuring the strategies;\n* A Python library, through which the data can be accessed; and\n* An efficient data cache module that avoids downloading the same content several times.\n\n## Types of strategies\n\n### Download strategy\n\nDownload strategy patterns use a given protocol to download content into the data cache.\nThey are configured with the `ResourceConfig` data model, using the scheme of the `downloadUrl` field for strategy selection.\nThe `configuration` field can be used to configure how the downloaded content is stored in the cache using the `DownloadConfig` data model.\n\nStandard downloaded strategies: *file*, *https*, *http*, *sftp*, *ftp*\n\n### Parse strategy\n\nParse strategy patterns convert content from the data cache to a Python dict.\nLike download strategies, they are configured with the `ResourceConfig` data model, using the `mediaType` field for strategy selection.\nAdditional strategy-specific configurations can be provided via the `configuration` field.\n\nStandard parse strategies: *application/json*, *image/jpg*, *image/jpeg*, *image/jp2*, *image/png*, *image/gif*, *image/tiff*, *image/eps*, *application/vnd.openxmlformats-officedocument.spreadsheetml.sheet*, *application/vnd.sqlite3*\n\n### Resource strategy\n\nResource strategy patterns can retrieve/upload data to external data services.\nThey are configured with the `ResourceConfig` data model, using the scheme of the `accessUrl` and `accessService` fields.\nThe scheme of the `accessUrl` is used for strategy selection.\n\n### Mapping strategy\n\nStrategies for mapping fields/properties in data models to ontological concepts.\n\n### Filter strategy\n\nFilter strategies can update the configuration of other strategies.\nThey can also update values in the data cache.\n\nStandard filter strategies: *filter/crop*, *filter/sql*\n\n### Function strategy\n\nFunction strategies are synchronous transformations that (normally) run directly on the server hosting the OTE service.\n\n### Transformation strategy\n\nTransformation strategies are a special form of a function strategy intended for long-running transformations.\nIn this sense, they represent asynchronous functions running in the background or on external resources.\n\nStandard transformation strategies: *celery/remote*\n\nThe transformation strategy has consolidated the execution of the\ntransformation with the `get()` method to unify the strategy interfaces.\n`get()` is intended to start an asynchronous process and return a\n*task_id* which can be queried using the `status()` method (outside of a pipeline).\n\n## Entry points for plugins\n\nThe way strategies are registered and found is through [entry points](https://packaging.python.org/en/latest/specifications/entry-points/).\n\nSpecial group names allow understanding the strategy type and the entry point values allow understanding of what kind of strategy a specific class implements.\nA full overview of recognized entry point group names can be seen in [Table of entry point strategies](#table-of-entry-point-strategies).\n\n### Defining entry points\n\nIn the following examples, let's imagine we have a package importable in Python through `my_plugin` and contains two download strategies and a single parse strategy:\n\n1. A peer-2-peer download strategy, implemented in a class named `Peer2PeerDownload` importable from `my_plugin.strategies.download.peer_2_peer`.\n2. A MongoDB download strategy, implemented in a class named `MongoRetrieve` importable from `my_plugin.strategies.mongo`.\n3. A MongoDB parse strategy, implemented in a class named `MongoParse` importable from `my_plugin.strategies.mongo`.\n\nThere are now various different ways to let the Python environment know of these strategies through entry points.\n\n#### `setup.py`\n\nIn the package's `setup.py` file, one can specify entry points.\nHere, an example snippet is shown using [setuptools](https://setuptools.pypa.io/):\n\n```python\n# setup.py\nfrom setuptools import setup\n\nsetup(\n # ...,\n entry_points={\n \"oteapi.download\": [\n \"my_plugin.p2p = my_plugin.strategies.download.peer_2_peer:Peer2PeerDownload\",\n \"my_plugin.mongo = my_plugin.strategies.mongo:MongoRetrieve\",\n ],\n \"oteapi.parse\": [\n \"my_plugin.application/vnd.mongo+json = my_plugin.strategies.mongo:MongoParse\",\n ]\n },\n)\n```\n\n#### YAML/JSON custom files\n\nUse custom files that are later parsed and used in a `setup.py` file.\n\n```yaml\nentry_points:\n oteapi.download:\n - \"my_plugin.p2p = my_plugin.strategies.download.peer_2_peer:Peer2PeerDownload\"\n - \"my_plugin.mongo = my_plugin.strategies.mongo:MongoRetrieve\"\n oteapi.parse:\n - \"my_plugin.application/vnd.mongo+json = my_plugin.strategies.mongo:MongoParse\"\n```\n\n```json\n{\n \"entry_points\": {\n \"oteapi.download\": [\n \"my_plugin.p2p = my_plugin.strategies.download.peer_2_peer:Peer2PeerDownload\",\n \"my_plugin.mongo = my_plugin.strategies.mongo:MongoRetrieve\"\n ],\n \"oteapi.parse\": [\n \"my_plugin.application/vnd.mongo+json = my_plugin.strategies.mongo:MongoParse\"\n ]\n }\n}\n```\n\n#### `setup.cfg`/`pyproject.toml`\n\nA more modern approach is to use `setup.cfg` or `pyproject.toml`.\n\n```ini\n[options.entry_points]\noteapi.download =\n my_plugin.p2p = my_plugin.strategies.download.peer_2_peer:Peer2PeerDownload\n my_plugin.mongo = my_plugin.strategies.mongo:MongoRetrieve\noteapi.parse =\n my_plugin.application/vnd.mongo+json = my_plugin.strategies.mongo:MongoParse\n```\n\n### Syntax and semantics\n\nAs seen above, there are a few different syntactical flavors of how to list the entry points.\nHowever, the \"value\" stays the same throughout.\n\n#### General Python entry points\n\nThe general syntax for entry points is based on `ini` files and parsed using the built-in `configparser` module described [here](https://docs.python.org/3/library/configparser.html#module-configparser).\nSpecifically for entry points the nomenclature is the following:\n\n```ini\n[options.entry_points]\nGROUP =\n NAME = VALUE\n```\n\nThe `VALUE` is then further split into: `PACKAGE.MODULE:OBJECT.ATTRIBUTE [EXTRA1, EXTRA2]`.\n\n#### OTEAPI strategy entry points\n\nFrom the general syntax outlined above, OTEAPI Core then implements rules and requirements regarding the syntax for strategies.\n\n1. A class *MUST* be specified (as an `OBJECT`).\n2. The `NAME` *MUST* consist of exactly two parts: `PACKAGE` and strategy type value in the form of `PACKAGE.STRATEGY_TYPE_VALUE`.\n3. The `GROUP` *MUST* be a valid OTEAPI entry point group, see [Table of entry point strategies](#table-of-entry-point-strategies) for a full list of valid OTEAPI entry point group values.\n\nTo understand what the strategy type value should be, see [Table of entry point strategies](#table-of-entry-point-strategies).\n\n### Table of entry point strategies\n\n| Strategy Type Name | Strategy Type Value | Entry Point Group | Documentation Reference |\n|:---:|:---:|:---:|:--- |\n| Download | [`scheme`](oteapi/models/resourceconfig.py) | `oteapi.download` | [Download strategy](#download-strategy) |\n| Filter | [`filterType`](oteapi/models/filterconfig.py) | `oteapi.filter` | [Filter strategy](#filter-strategy) |\n| Function | [`functionType`](oteapi/models/functionconfig.py) | `oteapi.function` | [Function strategy](#function-strategy) |\n| Mapping | [`mappingType`](oteapi/models/mappingconfig.py) | `oteapi.mapping` | [Mapping strategy](#mapping-strategy) |\n| Parse | [`mediaType`](oteapi/models/resourceconfig.py) | `oteapi.parse` | [Parse strategy](#parse-strategy) |\n| Resource | [`accessService`](oteapi/models/resourceconfig.py) | `oteapi.resource` | [Resource strategy](#resource-strategy) |\n| Transformation | [`transformationType`](oteapi/models/transformationconfig.py) | `oteapi.transformation` | [Transformation strategy](#transformation-strategy) |\n\n## Other OTEAPI-related repositories\n\n* [OTEAPI Services](https://github.com/EMMC-ASBL/oteapi-services) - a RESTful interface to OTEAPI Core\n* [OTELib](https://github.com/EMMC-ASBL/otelib) - a Python interface to OTEAPI Services\n* [OTEAPI Plugin Template](https://github.com/EMMC-ASBL/oteapi-plugin-template) - a [cookiecutter](https://cookiecutter.readthedocs.io/) template for OTEAPI Plugins\n\n## Installation\n\nOTEAPI Core can be installed with:\n\n```shell\npip install oteapi-core\n```\n\n### For developers\n\nIf you want to install OTEAPI Core to have a developer environment, please clone down the repository from GitHub and install:\n\n```shell\ngit clone https://github.com/EMMC-ASBL/oteapi-core /path/to/oteapi-core\npip install -U --upgrade-strategy=eager -e /path/to/oteapi-core[dev]\n```\n\nNote, `/path/to/oteapi-core` can be left out of the first line, but then it must be updated in the second line, either to `./oteapi-core`/`oteapi-core` or `.` if you `cd` into the generated folder wherein the repository has been cloned.\n\nThe `--upgrade-strategy=eager` part can be left out.\nWe recommend installing within a dedicated virtual environment.\n\nTo test the installation, you can run:\n\n```shell\ncd /path/to/oteapi-core\npytest\n```\n\nIf you run into issues at this stage, please [open an issue](https://github.com/EMMC-ASBL/oteapi-core/issues/new).\n\n## Using Docker with PostgreSQL\n\nDocker is an effective tool for creating portable, isolated environments for your applications.\nHere's an example of setting up a PostgreSQL instance using Docker:\n\n1. **Create a Docker volume**: Docker volumes enable data to persist across uses of Docker containers.\n In this context, we create a volume called pgdata to store database data.\n\n ```shell\n docker volume create pgdata\n ```\n\n2. **Start a Docker container**: Use the `docker run` command to initiate a new Docker container using the postgres image.\n Here's a breakdown of the options used in the command:\n\n `-d`: Runs the container in the background (detached mode), freeing up your terminal.\n\n `--name postgres`: Names the container postgres, allowing it to be referenced in future Docker commands.\n\n `-e POSTGRES_PASSWORD=postgres`: Sets an environment variable in the container to specify the PostgreSQL database password as postgres.\n\n `-p 5432:5432`: Maps port 5432 of the container to port 5432 of the host machine, letting applications on the host connect to the PostgreSQL database in the container.\n\n `-v pgdata:/var/lib/postgresql/data`: Mounts the pgdata volume at the path /var/lib/postgresql/data inside the container, which is the storage location for PostgreSQL data files.\n\n `--restart always`: Ensures the container restarts whenever it stops, unless it is manually stopped, in which case it only restarts when the Docker daemon starts, usually on system boot.\n\n ```shell\n docker run -d --name postgres \\\n -e POSTGRES_PASSWORD=postgres \\\n -p 5432:5432 \\\n -v pgdata:/var/lib/postgresql/data \\\n --restart always postgres\n ```\n\n## License\n\nOTEAPI Core is released under the [MIT license](LICENSE) with copyright © SINTEF.\n\n## Acknowledgment\n\nOTEAPI Core has been supported by the following projects:\n\n* **OntoTrans** (2020-2024) that receives funding from the European Union\u2019s Horizon 2020 Research and Innovation Programme, under Grant Agreement no. 862136.\n\n* **VIPCOAT** (2021-2025) receives funding from the European Union\u2019s Horizon 2020 Research and Innovation Programme - DT-NMBP-11-2020 Open Innovation Platform for Materials Modelling, under Grant Agreement no: 952903.\n\n* **OpenModel** (2021-2025) receives funding from the European Union\u2019s Horizon 2020 Research and Innovation Programme - DT-NMBP-11-2020 Open Innovation Platform for Materials Modelling, under Grant Agreement no: 953167.\n\n",
"bugtrack_url": null,
"license": "",
"summary": "Open Translation Environment (OTE) API.",
"version": "0.6.1",
"project_urls": {
"Changelog": "https://github.com/EMMC-ASBL/oteapi-core/blob/master/CHANGELOG.md",
"Documentation": "https://EMMC-ASBL.github.io/oteapi-core",
"Home": "https://github.com/EMMC-ASBL/oteapi-core",
"Issue Tracker": "https://github.com/EMMC-ASBL/oteapi-core/issues",
"Package": "https://pypi.org/project/oteapi-core",
"Source": "https://github.com/EMMC-ASBL/oteapi-core"
},
"split_keywords": [
"ote",
"ote-api"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "cbe1cdcb8a7e2d0bf2760e75ac03aeda6e51f20810921ad138e8587a28ef3820",
"md5": "a683e214e6048dc69888895cbcdaa06d",
"sha256": "9d9e8a9052452e2af69067a9d089f5b2f369713f705fe4b09018526ee397a98e"
},
"downloads": -1,
"filename": "oteapi_core-0.6.1-py3-none-any.whl",
"has_sig": false,
"md5_digest": "a683e214e6048dc69888895cbcdaa06d",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.9",
"size": 59959,
"upload_time": "2023-11-14T00:23:05",
"upload_time_iso_8601": "2023-11-14T00:23:05.499085Z",
"url": "https://files.pythonhosted.org/packages/cb/e1/cdcb8a7e2d0bf2760e75ac03aeda6e51f20810921ad138e8587a28ef3820/oteapi_core-0.6.1-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "fecd97ddc69a6e0a7a56f5624b819ef8e98619048b8a833a6a725a2b462a9756",
"md5": "930fe9be65636aefdeb5aad63416c0ac",
"sha256": "093198b34d48bc3009bf2b4676bcc61b106a1adb2af398b1791b23ba83b7472f"
},
"downloads": -1,
"filename": "oteapi_core-0.6.1.tar.gz",
"has_sig": false,
"md5_digest": "930fe9be65636aefdeb5aad63416c0ac",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.9",
"size": 57724,
"upload_time": "2023-11-14T00:23:07",
"upload_time_iso_8601": "2023-11-14T00:23:07.779233Z",
"url": "https://files.pythonhosted.org/packages/fe/cd/97ddc69a6e0a7a56f5624b819ef8e98619048b8a833a6a725a2b462a9756/oteapi_core-0.6.1.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2023-11-14 00:23:07",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "EMMC-ASBL",
"github_project": "oteapi-core",
"travis_ci": false,
"coveralls": false,
"github_actions": true,
"lcname": "oteapi-core"
}
