app-bricks-py

KO | EN

gitlite — search

#python #ai #typescript #golang #android #machine-learning #rust #docker #nodejs #kubernetes #awesome-list #vue #pytorch #mcp

(★ 31)

The code of the Arduino App Lab Bricks

app-bricks-py 최신버젼 다운로드

최종 버전 다운로드 (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# Arduino Apps Brick Library

The library is composed of configurable and reusable 'Bricks', based on optional infrastructure (executed via Docker Compose) and wrapping Python® code (to simplify code usage).

## What is a Brick?

A **Brick** is a modular, reusable building block that provides specific functionality for Arduino applications. Each Brick is self-contained with standardized configuration, consistent APIs, and optional Docker service definitions.

## Directory Structure

Every Brick must follow this standardized directory structure:

```
src/arduino/app_bricks/brick_name/
├── __init__.py                 # Required: Public API exports
├── brick_config.yaml          # Required: Brick metadata
├── brick_compose.yaml         # Optional: Docker services
├── README.md                  # Required: Documentation
├── [implementation_files.py]  # Brick logic
└── [assets]                   # Static resources
```

Brick usage examples live in the [app-bricks-examples](https://github.com/arduino/app-bricks-examples) repository, under the `bricks/` folder.

## Configuration variables

| Variable  | Description |
| ------------- | ------------- |
| APP_HOME  | Base application directory context  |
| LOCAL_DEV | To switch logic for local library development |
| APPSLAB_VERSION | To override the image versions referenced in brick_compose.yaml files |

## Library compile and build

To build wheel file suitable for release, use following commands:
```sh
pip install build
python -m build .
```
To build package as snapshot for latest development build, use following build command:
```sh
pip install build
python -m build --config-setting "build_type=dev" .
```

## Library development steps
To start the development, clone the repository and create a virtual environment.

Install the Taskfile CLI tool: https://taskfile.dev/installation/.

Then, run the following command to set up the development environment:

```sh
task init
```

This task will check the python version and install the required dependencies.

To force a specific Arduino App Lab container version, use 'APPSLAB_VERSION' environment variable.

## Linting and formatting

To improve the development experience in VS Code, we recommend adding a `.vscode` folder to the repository root containing the following JSON files:

- `extensions.json`

```json
{
  "recommendations": [
    "charliermarsh.ruff",
    "github.vscode-pull-request-github",
    "ms-python.python",
    "tamasfe.even-better-toml"
  ],
  "unwantedRecommendations": [
    "ms-python.pylint"
  ]
}
```

- `settings.json`

```json
{
    // Set the Python interpreter to the virtual environment
    "python.defaultInterpreterPath": "${workspaceFolder}/.venv",
    "flake8.enabled": false,  // Disable flake8 since we use ruff
    "ruff.enable": true,
    "python.testing.pytestArgs": [
        "tests"
    ],
    "python.testing.unittestEnabled": false,
    "python.testing.pytestEnabled": true,

// Linting and formatting settings on save
    "[python]": {
        // 1) use ruff as the default formatter
        "editor.defaultFormatter": "charliermarsh.ruff",
        
        // 2) automatically format the code on save
        // comment this setting if you don't want to automatically format your code on save
        "editor.formatOnSave": true,

// 3) apply secure linter fixes on save
        // comment this setting if you don't want to automatically fix with the linter your code on save
        "editor.codeActionsOnSave": {
            "source.fixAll.ruff": "explicit",
        }
    }
}
```

After adding those files, VS Code will suggest installing the Python and Ruff extensions, which are properly configured for this project.

Alternatively, you can use the Ruff CLI to safely auto-fix linting issues and format your code by running:

```sh
task lint
```

```sh
task fmt
```

## Testing

All tests must be added in tests/ folder. To execute tests, run command:
```sh
task test
```

or, to execute specific tests, use:
```sh
task test:arduino/app_bricks
```

Modules can use LOCAL_DEV=true env variable to set development specific configurations.

For development purposes, it is possible to point to development containers (instead of the released ones) using two variables:
```sh
export DOCKER_REGISTRY_BASE=ghcr.io/<githubuser>/
export DOCKER_PYTHON_BASE_IMAGE=app-bricks/python-apps-base:dev-pose-classification
```
Development containers are published by the dev CI (`docker-build.yml`) tagged as `dev-<branch-name>` (e.g. branch `pose-classification` → tag `dev-pose-classification`).

## Release

Release is based on tags pushed to `main`. A single workflow (`docker-publish.yml`) handles all container
releases: **the tag prefix is the `containers/` sub-folder to release**.

| Tag | What it releases |
|---|---|
| `bricks/X.Y.Z` | everything in `containers/bricks/` (`python-apps-base`, `models-downloader`) + Python `.whl` uploaded to GitHub Release |
| `ai/X.Y.Z` | everything in `containers/ai/` (the model runners) |

Release cycles for AI containers and Bricks are independent — they use separate folders and tag prefixes,
and can be released at any time without affecting each other.

After releasing a new version of AI containers, compose files that use AI containers are updated automatically via a generated PR.

**Dependencies**: base images in `containers/base/` are not released on their own. Whatever a tagged
group depends on is rebuilt first, in dependency order, and tagged with the same version — releasing
`bricks/X.Y.Z` builds `python-slim` and `python-base` before `python-apps-base`. No manual step required.

For development, the dev build pipeline (`docker-build.yml`) is triggered manually (`workflow_dispatch`) on a branch and builds the selected containers (or all of them), tagging the images as `dev-<branch-name>`. Dependent containers are built in the correct order — downstream containers wait for their upstream to finish and use the freshly built image.

See [`.github/README.md`](.github/README.md) for full CI documentation.

### Container layers

Library containers are based on a set of pre-defined Python base images, in `containers/base/`, that are
updated with a different frequency wrt library release.
Base images are never released on their own: they are rebuilt as a dependency of whichever group is being
released, and tagged with that release version.

Base images are required to:
* reduce the amount of updated layers during a single library update
* promote reuse of existing layers in multiple builds
* cache pre-compiled python libraries as much as possible

Non-base images should start from common base images for performance and disk usage needs.

## License
See [LICENSE](./LICENSE.txt) file for details.

## SBOM (Software Bill of Materials)
Each container ships its SBOM files, in SPDX format, under its `sbom-delta/` directory (e.g. `containers/ai/ei-models-runner/sbom-delta/`):

- `base.spdx.json` — packages of the base image the container derives `FROM` (declared as `sbom.runtime_base` in the container's `ci.json`)
- `full.spdx.json` — complete package list of the container image
- `delta.spdx.json` — packages added by the container on top of its base image

Delta SBOMs are produced at build time and attached to the GitHub Release. To (re)generate them locally, run:
```sh
task sbom:delta
```
optionally passing container names and the image tag to scan, e.g.:
```sh
task sbom:delta -- python-apps-base --version 1.0.0
```

**Note**: To run this task, you need `syft` installed and access to the container registry.

app-bricks-py

app-bricks-py 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

app-bricks-py

app-bricks-py 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

Download README