Skip to content

Add easy import surface for std-compiling + SpecResults, and expose runtime __version__#13

Merged
Yong2Sheng merged 6 commits intodevelopfrom
enhance/easy_imports_std_compiling
Feb 27, 2026
Merged

Add easy import surface for std-compiling + SpecResults, and expose runtime __version__#13
Yong2Sheng merged 6 commits intodevelopfrom
enhance/easy_imports_std_compiling

Conversation

@Yong2Sheng
Copy link
Copy Markdown
Owner

Summary

I improved ergonomics across the repo by defining a clearer “public” import surface and making version introspection available at runtime.

This PR includes:

  • An easy-import layer for standard star compiling
  • The same easy-import pattern for SpecResults in plot_spec_file.py
  • A lightweight __version__ attribute backed by distribution metadata

What changed

1) Easy imports for standard star compiling

  • I added a small re-export layer (via __init__.py) so the most commonly used standard-star compiling entry points can be imported from a higher-level namespace.
  • This reduces deep import paths and makes notebooks/scripts cleaner.

2) Easy imports for SpecResults

  • I applied the same pattern to SpecResults in plot_spec_file.py so I can import it without reaching into internal module paths.
  • The intent is to make SpecResults feel like a first-class public API object.

3) Runtime __version__ from packaging metadata

  • I exposed __version__ using importlib.metadata.version("researchcodes"), so the version comes from the installed distribution metadata rather than being duplicated in code.
  • This keeps version as a single source of truth (defined by packaging metadata) while still allowing researchcodes.__version__ at runtime.

Why

  • As the repo grows, deep import paths become harder to remember and more fragile during refactors.
  • A stable, intentional import surface improves usability and makes future reorganizations less disruptive.
  • Surfacing __version__ via metadata avoids maintaining duplicate version strings and aligns with modern pyproject.toml-based packaging.
  • But some less used functions for specific tasks such as paper revisions are still kept in the notebook or a module script in the same folder where the notebook lives.

How to test

# Standard star compiling (examples)
from researchcodes import write_std_h5  # plus other top-level re-exports, if applicable

# SpecResults (examples)
from researchcodes import SpecResults  # if re-exported at the package top level
# or
from researchcodes.plot_spec_file import SpecResults  # if re-exported at a module-level __init__.py

@Yong2Sheng Yong2Sheng merged commit fbf85ee into develop Feb 27, 2026
4 checks passed
@Yong2Sheng Yong2Sheng deleted the enhance/easy_imports_std_compiling branch February 27, 2026 17:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant