# madbot-community-abromics

Madbot **Data** plugin for Abromics: Python package `abromics-plugin`, import path `abromics_plugin`, main class [`AbromicsPlugin`](abromics_plugin/plugins.py), Django app config [`AbromicsPluginConfig`](abromics_plugin/apps.py).

Upstream: [madbot_community_abromics on GitLab](https://gitlab.com/ifb-elixirfr/madbot/plugins/community/madbot_community_abromics).

## What it does

Registers a Madbot plugin that exposes Abromics-backed data and file access so the Madbot API (and clients such as Abromics Analysis) can open connections and resolve datalinks. The connection payload from Abromics uses plugin id:

`abromics_plugin.plugins.AbromicsPlugin`

## Requirements

- Python **3.10+**
- A running **Madbot** API using the **same** interpreter / virtual environment as this package (and the same for **Celery** workers if you use them).
- Dependencies: `django`, `requests` (see [`pyproject.toml`](pyproject.toml)). Madbot’s `plugin_api` is expected to be on `PYTHONPATH` when Madbot runs.

## Install

Clone and install in editable mode from the directory that contains `pyproject.toml`:

```bash
git clone git@gitlab.com:ifb-elixirfr/madbot/plugins/community/madbot_community_abromics.git
cd madbot_community_abromics
pip install -e .
```

If your Madbot checkout provides a helper (e.g. a Pixi task in `api/` that installs this path), you can use that instead—what matters is that `import abromics_plugin` succeeds in the process that serves the API and runs background jobs.

**Docker:** add the same `pip install -e .` (or equivalent) to the API (and worker) image build, not only your laptop venv.

## Configure Madbot

1. Add the Django app module to `MADBOT_INSTALLED_PLUGINS` (comma-separated list in `.env`):

   ```env
   MADBOT_INSTALLED_PLUGINS=abromics_plugin,madbot_ena
   ```

   Include any other plugins you use; order is only relevant if you rely on specific discovery behaviour.

2. Restart the API and Celery (or reload as your deployment does).

3. After changing plugin metadata, run Madbot’s plugin reload if your setup uses it (e.g. `reload_plugins` management command) so schemas stay in sync.

If `POST /api/connections` returns **400** with `plugin` / `does_not_exist`, the runtime cannot import `abromics_plugin.plugins.AbromicsPlugin`—fix the install in **that** environment and restart.

## Package layout

| Path | Role |
|------|------|
| `abromics_plugin/` | Django app and plugin implementation |
| `abromics_plugin/plugins.py` | `AbromicsPlugin` (Data plugin class) |
| `abromics_plugin/apps.py` | `AbromicsPluginConfig` |

PyPI-style name: **`abromics-plugin`** (`[project].name` in `pyproject.toml`).

## CI / PyPI releases

On push to **`dev`**, GitLab CI runs [semantic-release](https://semantic-release.gitbook.io/) (conventional commits). If there is a releasable change, it bumps the version in `pyproject.toml` and `abromics_plugin/__init__.py`, updates `CHANGELOG.md`, builds the sdist/wheel, uploads to **PyPI**, and pushes the release commit.

**CI/CD variables** (Settings → CI/CD → Variables):

| Variable | Purpose |
|----------|---------|
| `GITLAB_TOKEN` | Project access token with **api** + **write_repository** (push tags/commits from the job) |
| `PYPI_TOKEN` | [PyPI API token](https://pypi.org/manage/account/token/) (upload scope); used as `twine` password with username `__token__` |

Local dry-run (optional): `pixi install -e dev && npm install && npx semantic-release --dry-run` (export the same env vars or use `.env` tooling—never commit tokens).

## License

[MIT](LICENSE) — Copyright (c) 2026 Abromics Team.
