semvec/pypi-packages huggingface dataset:
bblocks-client 0.0.2
OGC Blocks client
Requires Python: >=3.7
Keywords: ogc, ogc blocks, ogc rainbow

# bblocks-client

A Python client library for working with [OGC Blocks](https://ogcincubator.github.io/bblocks-docs/) registers.

OGC Blocks are reusable specification components that support validation, semantic annotation via JSON-LD,
and federation across distributed registers.

## Installation

```bash
pip install bblocks_client
```

Optional extras for validation and semantic uplift:

```bash
# JSON Schema validation
pip install bblocks_client[jsonschema]

# SHACL validation and semantic uplift (RDF/JSON-LD)
pip install bblocks_client[rdf]

# All extras
pip install bblocks_client[all]
```

## Usage

### Loading a register

```python
from ogc.bblocks.register import load_register

register = load_register("https://example.org/bblocks/register.json")

# Look up a block by identifier
bblock = register.get_item_summary("my.org.bblock-id")
```

Imported registers (dependencies) are loaded automatically. Pass `load_dependencies=False` to skip this.

### Accessing block metadata

`get_item_summary()` returns a `BuildingBlockSummary` with lightweight metadata.
`get_item_full()` fetches the full `BuildingBlock`, including examples and semantic uplift configuration.

```python
bblock = register.get_item_full("my.org.bblock-id")

print(bblock.name)
print(bblock.status)        # Status enum: stable, experimental, etc.
print(bblock.depends_on)    # Set of dependency identifiers
print(bblock.ld_context)    # URL to JSON-LD context
print(bblock.schema)        # Dict of media-type -> schema URL
```

### JSON Schema validation

Requires `bblocks_client[jsonschema]`.

```python
from ogc.bblocks.validate import validate_json

result = validate_json(bblock, {"type": "Feature", ...})
if not result.valid:
    print(result.exception)

# Or raise directly:
result.raise_for_invalid()
```

### SHACL validation

Requires `bblocks_client[rdf]`.

```python
from rdflib import Graph
from ogc.bblocks.validate import validate_shacl

graph = Graph().parse("data.ttl")
result = validate_shacl(bblock, graph)
print(result.report)
result.raise_for_invalid()
```

### Semantic uplift (JSON to RDF)

Requires `bblocks_client[rdf]`.

```python
from ogc.bblocks.semantic_uplift import uplift_json

rdf_graph = uplift_json(bblock, {"name": "Alice", ...})
print(rdf_graph.serialize(format="turtle"))
```

This applies the block's JSON-LD context to the input data, producing an RDF graph.
Pre- and post-processing steps (jq, SPARQL, SHACL rules) defined in the block are applied automatically.

## License

Apache 2.0
ccs-digitalmarketplace-utils 79.14.0
Common utils for Digital Marketplace apps.
Requires Python: <3.15,>=3.11

Digital Marketplace utils
=========================

![Python 3.11](https://img.shields.io/badge/python-3.11-blue.svg)
![Python 3.12](https://img.shields.io/badge/python-3.12-blue.svg)
![Python 3.13](https://img.shields.io/badge/python-3.13-blue.svg)
![Python 3.14](https://img.shields.io/badge/python-3.14-blue.svg)
[![PyPI version](https://badge.fury.io/py/ccs-digitalmarketplace-utils.svg)](https://badge.fury.io/py/ccs-digitalmarketplace-utils)

## What's in here?

* Digital Marketplace API clients
* Formatting utilities for Digital Marketplace
* Digital Marketplace logging for Flask using JSON Logging
* Utility functions/libraries for Amazon S3, Mailchimp, Notify, Cloudwatch
* Helper code for Flask configuration
* A formed version of Flask Feature Flags

## Logging from applications

When logging from applications you should write your message as a [format
string](https://docs.python.org/2/library/string.html#format-string-syntax) and pass any required
arguments to the log method in the `extra` named argument. This allows our logging to use them as
separate fields in our JSON logs making it much easier to search and aggregate on them.

```python
logger.info("the user {user_id} did the thing '{thing}'", extra={
    'user_id': user_id, 'thing': thing
})
```

Note that apart from not getting the benefit, passing the formatted message can be dangerous. User
generated content may be passed, unescaped to the `.format` method.

## Versioning

Releases of this project follow [semantic versioning](http://semver.org/), ie
> Given a version number MAJOR.MINOR.PATCH, increment the:
>
> - MAJOR version when you make incompatible API changes,
> - MINOR version when you add functionality in a backwards-compatible manner, and
> - PATCH version when you make backwards-compatible bug fixes.

To make a new version:
- update the version in the `dmutils/__init__.py` file
- if you are making a major change, also update the change log;

When the pull request is merged a GitHub Action will tag the new version.

## Pre-commit hooks

This project has a [pre-commit hook][pre-commit hook] to do some general file checks and check the `pyproject.toml`.
Follow the [Quick start][pre-commit quick start] to see how to set this up in your local checkout of this project.

## Licence

Unless stated otherwise, the codebase is released under [the MIT License][mit].
This covers both the codebase and any sample code in the documentation.

The documentation is [&copy; Crown copyright][copyright] and available under the terms
of the [Open Government 3.0][ogl] licence.

[mit]: LICENCE
[copyright]: http://www.nationalarchives.gov.uk/information-management/re-using-public-sector-information/uk-government-licensing-framework/crown-copyright/
[ogl]: http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/

[pre-commit hook]: https://pre-commit.com/
[pre-commit quick start]: https://pre-commit.com/#quick-start
forecast-in-a-box 0.5.4
Weather Forecast in a Box
Requires Python: >=3.11

See project's [readme](https://github.com/ecmwf/forecast-in-a-box/blob/main/README.md).

# Development

## Setup
There are two options:
1. create manually a `venv` and install this as an editable package into it,
2. use the [`fiab.sh`](../scripts/fiab.sh) script.

The first gives you more control, the second brings more automation -- but both choices are ultimately fine and lead to the same result.

For the first option, active your venv of choice, and then:
```
mkdir -p ~/.fiab
uv pip install --prerelease=allow --upgrade -e .[test] # the --prerelease will eventually disapper, check whether pyproject contains any `dev` pins
pytest backend # just to ensure all is good
```

For the second option, check the `fiab.sh` first -- it is configurable via envvars which are listed at the script's start.
In particular, you can change the directory which will contain the venv, and whether it does a PyPI-released or local-editable install.
Note however that in case of the local-editable installs, you *must* execute the `fiab.sh` with cwd being the `backend`, as there is `pip install -e.`.

### Frontend Required
The frontend is actually expected to be present as artifact _inside_ the backend in case of the editable install.
See the [`justfile`](../justfile)'s `fiabwheel` recipe for instruction how to build the frontend and create a symlink inside the backend.

Backend wheels on pypi do contain a frontend copy -- you can alternatively pull a wheel and extract the built frontend into the local install.

## Developer Flow
Primary means is running `ruff`, `ty`, and `pytest`, with the config being in `pyproject.toml`.
Ideally, you utilize the `val` recipe from the [justfile](./justfile) here, and install pre-commit hooks.

Type annotations are present and enforced.

In the [`bigtest.py`](../scripts/bigtest.py) there is a larger integration test, triggered at CI in addition to the regular `pytest` -- see the [github action](../.github/workflows/bigtest.yml) for execution.

## Architecture Overview
Consists of a four primary components:
1. JavaScript frontend as a stateless page, basically "user form → backend request" -- located at [frontend](../frontend),
2. FastAPI/Uvicorn application with multiple routes, organized by domain: auth, job submission & status, model download & status, gateway interaction, ...
3. standalone "gateway" process, expected to be launched at the beginning together with the Uvicorn process, which is the gateway to the [earthkit-workflows](https://github.com/ecmwf/earthkit-workflows),
4. persistence, based on a local `sqlite` database.

Configuration is handled by the `config.py` using pydantic's BaseSettings, meaning most behaviour is configurable via envvars -- see `fiab.sh` or tests for examples.
See [tuning and configuration](../docs/tuningAndConfiguration.md) guide for more.