You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Core source lives in `orthosnap/`, with the CLI entry point in `orthosnap/orthosnap.py` and shared utilities split across helper modules (for example `helper.py`, `writer.py`). Tests mirror runtime paths under `tests/` (`unit/` for isolated logic, `integration/` for CLI flows) and reuse fixtures in `tests/samples/`. Documentation is authored with Sphinx in `docs/`; build artifacts land in `docs/_build/` during CI. Reusable data for demonstrations ships in `samples/`.
5
+
6
+
## Build, Test, and Development Commands
7
+
Create an isolated environment (`python -m venv .venv && source .venv/bin/activate`) before installing. Run `make install` to install the package locally so the `orthosnap` console script is available. Use `make test.fast` for the default CI-equivalent quick check, or `make test.unit` and `make test.integration` when focusing on a specific layer. `make test.coverage` produces `unit.coverage.xml` and `integration.coverage.xml` for upload to Codecov; clean any generated FASTA outputs before committing.
8
+
9
+
## Coding Style & Naming Conventions
10
+
Target Python 3.9–3.13 and follow PEP 8: four-space indentation, snake_case functions, PascalCase classes, and descriptive module-level constants. Keep functions small, prefer explicit variable names (e.g., `taxa_counts` over `tc`), and include short docstrings for public helpers. Align logging and user-visible messages with existing phrasing in `orthosnap/helper.py`. When adding CLI arguments, route parsing through `parser.py` to remain consistent.
11
+
12
+
## Testing Guidelines
13
+
Pytest drives all suites. Mark unit-only tests with the default markers and integration cases with `@pytest.mark.integration`. Place new unit tests beside the feature under `tests/unit/` and use fixtures from `tests/samples/` where possible. Run `python -m pytest -k <pattern>` to iterate during development, and ensure `make test` succeeds before opening a pull request. Aim to keep coverage steady; add regression tests for every CLI flag or branch condition.
14
+
15
+
## Commit & Pull Request Guidelines
16
+
Write concise, present-tense commit messages (e.g., `add delimiter argument`) and group related changes. Reference issues in the body using `Fixes #<id>` when relevant. For pull requests, summarise behaviour changes, call out new dependencies, and attach command outputs or screenshots when UX changes. Confirm CI passes, ensure docs stay accurate (update Sphinx sources when CLI flags change), and request at least one review before merging.
17
+
18
+
## Environment & Documentation Tips
19
+
Use `requirements.txt` for runtime and packaging deps (supports CPython 3.9 through 3.13) and install doc tooling via `pipenv` inside `docs/` when updating the Sphinx site (`cd docs && pipenv run make html`). Avoid checking in files under `docs/_build/` or temporary trees left by integration tests.
20
+
21
+
## Performance Improvements In Progress
22
+
- Replace whole-tree `copy.deepcopy` calls in `orthosnap/orthosnap.py` with subtree-level cloning so we only touch the relevant clade per iteration.
23
+
- Precompute a parent lookup for tip nodes to let `get_subtree_tips` reuse cached structure instead of copying the tree for every duplicate gene check.
24
+
- Track `assigned_tips` as a set throughout execution to skip repeated list-to-set conversions while filtering already-handled sequences.
0 commit comments