Adopt shared checksum-pinned osteosarc test assets for RNA-backed effect comparisons

Open
  • Is something wrong?
#464 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
testing, tooling

Research direction

Start with the shared osteosarc / vaccine-rna-v1 convention and the linked Varcode issues #259, #421, and #423, then review the related Isovar and Vaxrank work. Identify Varcode's existing test-data acquisition and annotation-regression entry points before making changes. Done means cache reuse works across consumers, offline and tamper checks pass, and annotation expectations remain unchanged.

Written by the indexing model from the issue text.

Description

Requested follow-up

Reuse the proposed OpenVax shared, content-addressed osteosarc test-data cache for RNA-backed annotation/haplotype regressions, without adding a Varcode runtime dependency on Vaxrank or treating RNA fixture membership as DNA annotation truth.

Vaxrank's test/osteosarc-shared-downloader branch exports a portable subset from Isovar commit 0cad5b275c852263a1c77722aa463fe5568b2c76: 49 cases / 44 original vaccine loci, 98 original BAM/index assets (4.1 MB). Manifest fields retain native alleles, original GRCh38 identities, source product IDs/URLs and deliberate read-selection provenance. It does not include complete genome/annotation references or an SV truth set.

Shared convention: dataset osteosarc / vaccine-rna-v1; datacache namespace openvax; OPENVAX_DATA_CACHE or explicit root; objects at <root>/objects/sha256/<sha256><original suffixes>. Validate immutable URL downloads and cache hits using the pinned size and SHA-256. Keep scientific dataset revisions separate from package versions. Generic bundle support belongs in openvax/datacache#59.

For Varcode:

  • Use the same pinned original-read objects where relevant to RNA/compound-haplotype comparisons, with explicit acquisition separate from tests.
  • Keep independently pinned genomic/cDNA/protein references and expected effects as separate assets; a BAM or upstream peptide annotation is not an independent protein oracle.
  • Preserve native assembly/reference identity, particularly the GRCh37 NR2F2 and mitochondrial cases. Do not identify variants by gene or conflate nearby MAP2 alleles.
  • Preserve all DNA-only/transcript outcome candidates when comparing them with RNA-derived interpretations; unresolved RNA is not evidence of an absent DNA event.
  • Test cross-consumer cache reuse, offline execution, tamper rejection and unchanged annotation expectations. Prefer a neutral shared dataset manifest/registry when one is available, not imports from Vaxrank's downloader.

Related: #259, #421, #423; openvax/isovar#306; openvax/vaxrank#482. This is test-data adoption, not a request to implement RNA assembly in Varcode.

Dominant language
Python
Stars
88
Forks
28
Avg merge
3h 17m
Merged PRs (30d)
52

Getting set up

First steps

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

More from openvax/varcode

All issues in openvax/varcode

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.