NVIDIA-NeMo / NVIDIA-NeMo/Safe-Synthesizer
Clarify and restrict TrainingBackend internal API surface
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 38
- Forks
- 11
- Avg merge
- 4d 17h
- Merged PRs (30d)
- 9
Description
Priority Level
Medium
Task Summary
Several TrainingBackend methods are public by name but are effectively internal pipeline steps or subclass-only extension points (e.g. maybe_quantize, prepare_config, prepare_params, save_model). This makes it unclear which methods are safe for external callers.
Goal:
- Define a clear API boundary:
- Keep only true external entrypoints public.
- Mark internal orchestration/helpers as private (
_...) where appropriate. - Preserve subclass extension points intentionally and document them as subclass-only.
Technical Details & Implementation Plan
No response
Dependencies
No response
Contributor guide
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.
Research direction
Start by locating the TrainingBackend definition and reviewing maybe_quantize, prepare_config, prepare_params, and save_model to distinguish external entrypoints from pipeline helpers and subclass extension points. Done means internal methods use private naming where appropriate, intentional subclass-only hooks are documented, and the public API boundary is clear.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend-api-design
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100