Discussion: deprecate `read_imro`

Open

#351 opened on May 27, 2025 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty: 5/5
Estimated time: Over a week
Newbie friendliness: 35/100

Issue type: Refactor
Clarity: Mostly clear
Activity status: Quiet
Tech stack: python
Domain: backend

Research direction

Start in src/probeinterface/neuropixels_tools.py at read_imro and _read_imro_string, then inspect pull request #349 and callers to determine whether standalone IMRO reading is used. Done means the project has a settled decision on moving the inference logic and deprecating or retaining read_imro, with the resulting scope documented.

Written by the indexing model from the issue text.

Description

When discussing this pull request with @chrishalcrow, I’ve been thinking about the following:

Why do we expose read_imro directly?

The private function _read_imro_string is the one actually used by SpikeGLX and Open Ephys, while read_imro is just a wrapper around it that, for a reason that I can't remember, is exposed.

To make read_imro work, we need quite a bit of logic to infer the imDatPrb_pn (probe model number) from imDatPrb_type (probe type). This code is complex and since it was determined through trial and error when we did not have a general table, maybe not very reliable:

https://github.com/SpikeInterface/probeinterface/blob/27137e99bd31a65d058d34820803ca7be3b2bfa5/src/probeinterface/neuropixels_tools.py#L633-L651

This was necessary when our probe descriptions were based on the probe type. However, now that the official metadata table is organized around imDatPrb_pn (probe part number), this complexity is no longer needed. In other words, this logic doesn’t serve the key functionality anymore, which is reading neuropixel metadata.

Additionally, I’m not sure exposing the functionality to read IMRO tables on their own makes sense. These tables are embedded in the meta file, and trying to read them independently seems like a feature no one has asked for.

Proposed solution:

Move the logic for inferring imDatPrb_pn from imDatPrb_type out of the core function (_read_imro_string) and into the wrapper (read_imro), keeping the complexity at the periphery.
If there is no use for stand-alone reading of imro tables then deprecate read_imro and eventually remove it. This will allow us to eliminate code that is no longer needed now that we can rely on the metadata table.

Dominant language: Python
Stars: 85
Forks: 49
Avg merge: 13h 47m
Merged PRs (30d): 3

Contributor guide

No contributing guide indexed for this repository

First steps

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

Similar issues

slack-gif-creator: validate_gif() multiplies the last frame's duration by the frame count, so reported duration/fps are wrong (1.0s GIF reported as 1.8s) Open

Difficulty 2/5 1-3 hours Newbie friendliness 75/100

anthropics/skills#1811 · 1 comment · Opened Sep 23, 2026
App fails to start with gradio 6 (allowed by `gradio>=5.49.1`) Open

Difficulty 2/5 1-3 hours Newbie friendliness 75/100

speaches-ai/speaches#678 · Opened Sep 23, 2026
ModuleNotFoundError: No module named 'mcp.server.fastmcp'. Open

bug

Difficulty 2/5 1-3 hours Newbie friendliness 75/100

datalayer/mcp-compose#42 · Opened Sep 23, 2026
import spacy fails with ModuleNotFoundError: No module named 'click' Open

Difficulty 2/5 1-3 hours Newbie friendliness 75/100

conda-forge/spacy-feedstock#177 · Opened Sep 23, 2026
humaneval: extract_function_body corrupts a fenced body-only reply, so the same correct code scores INCORRECT fenced and CORRECT unfenced Open

Difficulty 2/5 1-3 hours Newbie friendliness 70/100

UKGovernmentBEIS/inspect_evals#2523 · Opened Sep 23, 2026

More Python issues