fix: handle non-BGZF gzip VCFs from bcftools -Oz in readVcf (#32)

[jmg421]

Problem

readVcf() crashes with a confusing htslib/Rsamtools error when given a .vcf.gz file compressed with bcftools -Oz (or plain gzip). These files are valid gzip but are not BGZF — they lack the BC extra subfield that htslib requires. The user sees something like:

Error in .Call2("tabix_read", ...) : failed to open ...

Reported in #32.

Root cause

.checkFile() unconditionally calls TabixFile(x) on any .gz path. htslib then rejects the non-BGZF file at the C level with no actionable message.

Fix

Three new internal helpers, all in R/methods-readVcf.R:

• .is_bgzf(path) — reads the 18-byte gzip header and checks for the BGZF BC extra subfield (bytes 13–14). Zero dependencies, pure R.
• .ungzip_vcf(path) — decompresses a regular-gzip VCF to a tempfile() plain VCF.
• .prepareFile(x) — called at the top of both readVcf(character, ANY) and readVcf(character, missing) before .checkFile(). If the file is gzip but not BGZF it decompresses to a temp file and tags it with attr(, "tmpfile") so the caller can register on.exit(unlink(...)) in its own frame — ensuring the temp file lives for the full readVcf call and is deleted immediately after.

Behaviour

Input	Before	After
bcftools -Oz / gzip compressed .vcf.gz	❌ htslib error	✅ reads correctly, emits informative message suggesting bgzip
BGZF (bgzip) compressed .vcf.gz	✅	✅ unchanged
Plain .vcf	✅	✅ unchanged
TabixFile input	✅	✅ unchanged

Testing

Verified with four inline Rscript cases: plain VCF, BGZF, regular gzip, and temp-file cleanup. All pass. Existing unit tests unaffected (pre-existing failures are due to missing optional packages snpStats, TxDb.*, etc. — not introduced by this PR).

Closes #32

[vjcitn]

Checking the source corresponding to this PR

Last 13 lines of output:
  Test files with failing tests
  
     test_predictCoding-methods.R 
       test_predictCoding_empty 
       test_predictCoding_exon_intron_boundary 
       test_predictCoding_nonsense_DBS 
  
     test_VRanges-class.R 
       test_VRanges_vcf 
  

[vjcitn]

I want eventually to provide a guideline on PRs in our Bioconductor documentation. Here's a basic concern, I want this to be aired openly. My prompt:

We have a situation in which 12 or so PRs have been entered, each one addressing an open issue. But the commits in the PRs are cumulative -- the code changes addressing issue 1 are included in the PR addressing issue 2. Is it appropriate to issue a guideline avoiding such a situation?

Claude's response:

Yes, that's worth a guideline — this is a common workflow mistake and there's an established fix.

What's happening: each PR was branched off the previous one (or off a branch that already had prior fixes merged in), rather than off a shared base like main. So PR #2 shows PR #1's commits as part of its diff, PR #3 shows #1 and #2's, and so on. This causes real problems: reviewers on PR #5 have to mentally filter out four other issues' worth of changes to see what's actually new; if PR #2 gets rejected or reworked, every PR stacked on top has to be rebased; merge order becomes rigid (you can't merge #7 before #3 even if #7 is ready and #3 isn't); and if two PRs are merged out of order, you can get duplicate-commit noise or conflicts in the history.

A guideline addressing it should specify two things:

Each PR branches from the current tip of main (or whatever the trunk is), not from another feature branch, unless the work genuinely depends on unmerged code.

When a PR does legitimately depend on another unmerged PR (a real stacked-PR case), the PR description should say so explicitly and the diff view should be scoped to just the new commits — GitHub and GitLab both support comparing against the dependency branch rather than main, and tools like gh pr or Graphite handle stacks properly so reviewers only see incremental changes.

So the guideline isn't "never stack PRs" — sometimes sequential dependent work is unavoidable. It's "branch from trunk by default, and if you must stack, mark it as a stack and keep diffs scoped to the delta." Given you've got 12 independent issues, most of these probably didn't need to depend on each other at all — this sounds like everyone just kept branching off the last person's branch out of convenience.

[vjcitn]

Since the PRs suffer from this cumulative form I am inclined to close them, but there is still some utility in mapping to the associated issues. Since the latest PR does not lead to a passing R CMD check, I will not merge it. I will spend a little more time considering how to close out open issues of significance.