OSDU Python SDK

Contents

• OSDU Python SDK
  • Contents
• Introduction
• Getting Started
  • Installation from source
  • Installation from Package Registry
  • Impersonation
  • Testing
    • Running E2E Tests
    • Running CSP tests
  • Release Process
  • Release Notes
    • 0.28
    • 0.17
  • Licence

Introduction

The Python SDK is a package to interface with OSDU microservices.

Interactions with OSDU services are cloud platform-agnostic by design. However, there are specific implementation requirements by cloud platforms, and the OSDU R3 Prototype provides a dedicated Python SDK to make sure that interactions are independent from the cloud platforms.

The Python SDK must be installed on the machine that uses OSDU services.

In OSDU R3 Prototype, the SDK encapsulates calls to the ODES Storage and Search services.

Also, in osdu_api.providers folder the SDK provides common interfaces for writing cloud-specific implementations for authorization and accessing cloud storages. In this osdu_api.providers folder CSP code is stored.

Getting Started

Installation from source

1. Pull the latest Python SDK's changes from https://community.opengroup.org/osdu/platform/system/sdks/common-python-sdk

2. Use Python 3.13. Also, it is highly recommended using an isolated virtual environment for development purposes (Creation of virtual environments: https://docs.python.org/3.11/library/venv.html)

3. Make sure you have setuptools and wheel installed

pip install --upgrade setuptools wheel

4. Change directory to the root of PythonSDK project

cd path/to/python-sdk

5. Make sure osdu-api isn't already installed

pip uninstall osdu-api

6. Install Python SDK

pip install '.[common]'

Example import after installing: from osdu_api.clients.storage.record_client import RecordClient

Installation from Package Registry

pip install 'osdu-api' --extra-index-url=https://community.opengroup.org/api/v4/projects/148/packages/pypi/simple

Impersonation

If client objects are initialized with a user_id argument, both on-behalf-of and x-on-behalf-of headers are set to that value. This covers Entitlements-based impersonation (GC, baremetal/core-plus) and Azure/Istio paths without requiring an environment variable.

Testing

Running E2E Tests

Specify of end-services URLs into tests/osdu_api.yaml and run

pip install '.[dev, common]'
pytest

Running CSP tests

export CLOUD_PROVIDER=<cloud_provider>
pip install '.[dev, common]'
pytest

For Google Cloud, you can select the type of token to use: ID token or Access token.

You can configure this via the GC_ID_TOKEN environment variable. Here's how to set it:

• for enabling ID token: 'y', 'yes', 'on', 'true' (case-insensitive)
• for using Access token: any other value, or don't set the variable at all

Release Process

Releases are fully automated via GitLab CI using a continuous-release model.

How it works

1. Open an MR targeting master (or release/X.Y) and add one of:

   • Impact::Patch — bumps the patch digit (e.g. 1.2.0 → 1.2.1)
   • Impact::Minor — bumps the minor digit (e.g. 1.2.0 → 1.3.0)
   • Impact::Major — bumps the major digit (e.g. 1.2.0 → 2.0.0)

2. On merge, the determine-release-version CI job scans merged MRs since the last tag and computes the next version.

3. The create-python-tag job writes the new version to VERSION, commits it, and pushes a Git tag vX.Y.Z.

4. The tag pipeline publishes osdu-api to:

   • OpenGroup GitLab Package Registry — https://community.opengroup.org/api/v4/projects/148/packages/pypi/simple
   • TestPyPI — https://test.pypi.org/simple
   • PyPI — https://pypi.org/simple

VERSION file

The VERSION file (repo root) contains the current stable base version (plain semver, e.g. 1.2.0).

• Stable builds (tagged): use the version as-is.
• Dev builds (untagged): pyproject.toml appends .dev{BUILD_ID}+{SHA} automatically.

Do not manually edit VERSION unless aligning the branch after a release cycle (e.g. when merging a release branch back to master). The CI pipeline manages VERSION for every tagged release.

Branch conventions

Follow the dual-branch model:

• fix/<name> — MR source branch; push triggers compile pipeline.
• trusted-fix/<name> — mirror branch; triggers trusted child pipeline (acceptance tests, Sonar).

After every commit to fix/<name>:

git checkout trusted-fix/<name>
git merge --ff-only fix/<name>
git checkout fix/<name>
git push origin fix/<name> trusted-fix/<name>

Both branches must point at the same SHA before CI is polled.

---

Release Notes

0.29

Updated project structure and added support for Python 3.13. Dual publishing to PyPi and OpenGroup package registry.

0.28

From this release verification of SSL certificates is enabled by default. If your environment is using self-signed certificates or a private CA this can be disabled by setting the environment variable OSDU_API_DISABLE_SSL_VERIFICAITON to iknowthemaninthemiddle.

0.17

Starting from this release each particular client class has 2 more optional parameters: provider and the corresponding client service URL. This was done in order to make using osdu_api.ini file optional. If you are not using named arguments in initializing your clients it can break your code since the order of parameters was changed.

Licence

Copyright © Amazon Web Services Copyright © Google LLC Copyright © EPAM Systems

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

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. A package to interface with OSDU microservices