NeuroTechX / NeuroTechX/moabb

Ship the reference benchmark pipelines in the package, with an accessor

Open
#1,149 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
1.1k
Forks
264
Avg merge
1d 13m
Merged PRs (30d)
23

Description

The 26 .yml + 2 .py configs in the repo-root pipelines/ directory ship in no artifact — not the 1.5.0 wheel, not the sdist, not pip install git+…@<sha> (PEP 517 builds the wheel). MANIFEST.in alone would not fix it: it governs the sdist, and include-package-data reaches the wheel only for files inside a package — recursive-include docs … ships nothing, include moabb/datasets/summary_*.csv ships all five.

So pipelines="./pipelines/" resolves only from a checkout, and the documented route to the reference pipelines is the GitHub link in plot_benchmark.py.

Downstream. Four cases, none of which produced an issue about the shared cause:

  • #640 — hand-written CSP+LDA missed the published number; resolved with a link.
  • #639 — answered by hand-transcribing CSP.yml into Python in a comment.
  • #1072 (open) — reproducibility thesis on pipelines="../pipelines", datasets skipped silently.
  • facebookresearch/neuroaicov_ts_lr.yaml:10 cites TSLR.yml, then diverges in three steps.

People who want the reference approximate it, and the result is plausible enough to publish.

In-repo. Nothing exercises these configs — CI uses the FakePipeline fixtures. from:/name: resolve at runtime, so an upstream rename goes undetected until a user hits it; #1123 renamed imports one layer beneath them. All 28 still resolve against current deps, but nothing asserts it.

Proposal

  1. Ship the configs as moabb/pipelines/configs/MANIFEST.in plus an explicit [tool.setuptools.package-data] entry; no __init__.py, so packages.find still ignores it.
  2. moabb.pipelines.get_benchmark_pipelines(paradigm=None, dir_name=None)parse_pipelines_from_directory over that directory, returning the list-of-dicts benchmark() has accepted since #826. Mirrors moabb.datasets.base.get_summary_table.
  3. benchmark(pipelines=None) and run.py --pipelines default to it, with a DeprecationWarning when ./pipelines/ exists and nothing was passed — rather than CWD-dependent resolution. Partly addresses #175.
  4. Warn when parse_pipelines_from_directory gets a valid directory with zero configs; it currently returns [] silently, which is what #1072 hit. Its .py branch also does an unguarded foo.PIPELINE.
  5. Parametrized test constructing every packaged config, so a rename is a red build rather than a user report.

In use:

from moabb import benchmark
from moabb.pipelines import get_benchmark_pipelines

pipelines = get_benchmark_pipelines(paradigm="LeftRightImagery")
results = benchmark(pipelines=pipelines, evaluations=["WithinSession"])

Move or mirror? git mv pipelines moabb/pipelines/configs is simpler and removes the CWD question in (3), but breaks external blob/develop/pipelines/<file> links. The alternative keeps pipelines/ canonical plus a synced copy, costing a pre-commit hook and an identity test. I lean move; your call.

Happy to implement.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the repo-root pipelines/, MANIFEST.in, the packaging configuration, moabb/datasets/base.py, parse_pipelines_from_directory, benchmark(), and run.py. Trace how package data and pipeline paths are resolved, then determine whether the configs should move or be mirrored. Done means packaged installs expose the reference pipelines, the accessor and defaults behave as proposed, empty or invalid configurations are covered, and tests construct every config.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
build-system, machine-learning, testing
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.