Proposal: Public `register_reader()` API for custom file format extensibility

[Aman-Cool]

Is your feature request related to a problem? If so, please describe.

Currently, extending AIDRIN to support new file formats requires modifying internal package code. A new reader must be added under aidrin/file_handling/readers/, and the internal READER_MAP dictionary in file_parser.py must be updated manually.

This works for core-maintained formats but makes external extensibility difficult. Users working with proprietary binary formats, domain-specific HDF5 schemas, or non-local storage backends (e.g., S3, HDFS, REST APIs) must either fork the repository or monkey-patch READER_MAP at runtime. Both approaches introduce maintenance overhead and reduce usability for research-oriented workflows.

There is currently no public extension mechanism for registering custom readers.

---

Describe the solution you'd like

Introduce a public API:

register_reader(extension: str, reader_cls: Type[BaseFileReader], force: bool = False)

This function would allow users to register custom reader implementations without modifying AIDRIN internals.

Expected behavior:

• Validate that reader_cls subclasses BaseFileReader
• Prevent silent overrides of existing extensions unless force=True
• Maintain backward compatibility with existing read_file() dispatch logic

Example usage:

from aidrin.file_handling.readers.base_reader import BaseFileReader
from aidrin.file_handling.file_parser import register_reader
import pandas as pd

class MyFormatReader(BaseFileReader):
    def read(self) -> pd.DataFrame:
        raw = my_loader(self.file_path)
        return pd.DataFrame(raw)

register_reader(".myf", MyFormatReader)

Since read_file() already dispatches via READER_MAP[file_type](...).read(), no additional changes to the dispatch mechanism would be required.

---

Describe alternatives you've considered

• Forking the repository to add custom readers directly
• Monkey-patching READER_MAP at runtime

Both approaches work technically but introduce maintenance burden and are not ideal for long-term extensibility.

---

Additional Information

Upcoming multi-format support (e.g., Zarr, ROOT) follows the same structural pattern as existing readers. Introducing a public registration API would:

• Provide a formal extension mechanism
• Encourage community-contributed readers (Parquet, netCDF, Feather, etc.)
• Reduce the need for forks
• Make AIDRIN more adaptable in research environments

Happy to draft a PR if this direction aligns with the project’s roadmap.

[Aman-Cool]

Hey @sbyna @just @kaveenh, so I went ahead and started working on this!

Opened #66 as the first PR, it's just the register_reader() function in file_parser.py for
now. It handles the subclass validation, blocks silent overrides unless you pass force=True,
and keeps SUPPORTED_FILE_TYPES in sync automatically so the frontend picks it up too.

Plan is to follow up with:

1. Tests in the next PR
2. A clean public __init__.py export + usage example after that

Trying to keep each PR small and focused so it's easier to review.

lmk if anything looks off or if you'd want it structured differently before I go further!