Several issues and a feature request

[charlesfoster]

Hi,

I thought I would try out VILOCA but I'm encountering several issues, both with my data and with the test data.

Issues with printing the version of VILOCA

This is probably the simplest issue to fix. When viloca --version using a conda installation or docker image, I get the following:

# docker
$ docker run -v $PWD:$PWD -w $PWD quay.io/biocontainers/viloca:1.1.0--pyhdfd78af_0 viloca --version
1.0.0

# conda
(viloca) $ viloca --version
/Users/charles/miniforge3/envs/viloca/lib/python3.10/site-packages/viloca/cli.py:50: UserWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html. The pkg_resources package is slated for removal as early as 2025-11-30. Refrain from using this package or pin to Setuptools<81.
  from pkg_resources import (get_distribution, DistributionNotFound)
1.0.0

In short: the version number doesn't align with the installed version. I'm running v1.1.0 but --version flag returns 1.0.0.

pkg_resources problem

As seen above in the conda code block, the conda installation has pkg_resources issues. This can be solved by pinning an earlier version of setuptools or transitioning to importlib.

i.e. in cli.py change:

use_pkg_resources = False
all_dirs = os.path.abspath(__file__).split(os.sep)
base_dir = os.sep.join(all_dirs[:-all_dirs[::-1].index('viloca')])
version_fname = os.path.join(base_dir, '.version')
if os.path.exists(version_fname):
    # probably installed using Autotools, e.g: bioconda package - the current recommended way
    with open(version_fname, 'r') as version_file:
        __version__ = version_file.read()
else:
    # probably installed using setup.py
    from pkg_resources import (get_distribution, DistributionNotFound)
    try:
        __version__ = get_distribution('viloca').version
    except DistributionNotFound:
        __version__ = 'unknown'
        print("cannot find version", file=sys.stderr)
    else:
        use_pkg_resources = True

to:

all_dirs = os.path.abspath(__file__).split(os.sep)
base_dir = os.sep.join(all_dirs[:-all_dirs[::-1].index('viloca')])
version_fname = os.path.join(base_dir, '.version')
if os.path.exists(version_fname):
    # probably installed using Autotools, e.g: bioconda package - the current recommended way
    with open(version_fname, 'r') as version_file:
        __version__ = version_file.read()
else:
    # fallback: determine version via importlib.metadata (PEP 566)
    try:
        from importlib import metadata as importlib_metadata  # Python ≥3.8
    except ImportError:
        import importlib_metadata  # type: ignore

    try:
        __version__ = importlib_metadata.version("viloca")
    except importlib_metadata.PackageNotFoundError:
        __version__ = "unknown"

I don't think there are necessary changes to other files, but you would know better than me :)

VILOCA not finding any reads

This is the most important problem I've encountered. VILOCA isn't giving any results because it states No reads found in the requested region. For example, using the test data sourced from GitHub:

$ viloca run -b test_aln.cram -f test_ref.fasta
/Users/charles/miniforge3/envs/viloca/lib/python3.10/site-packages/viloca/cli.py:50: UserWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html. The pkg_resources package is slated for removal as early as 2025-11-30. Refrain from using this package or pin to Setuptools<81.
  from pkg_resources import (get_distribution, DistributionNotFound)
No reads found in the requested region 

If I run the same command with VILOCA v1.0.0 I get results. It seems like something has gone wrong in the v1.0.0 --> v1.1.0 transition.

Output directory option?

Could you consider adding an option to specify an output directory? It would be useful rather than all outputs going into the working directory.

Cheers,
Charles

[LaraFuhrmann]

Dear Charles,

Thank you for testing our tool using the Docker image and for providing such detailed feedback on the issues you encountered.

We've updated the version and addressed your suggestion regarding the pkg_resources issue.

Regarding the problem where "VILOCA does not find any reads," we were unable to reproduce this using the Docker image (Note that the test data was copied to the current work directory.):

docker run -v $PWD:$PWD -w $PWD quay.io/biocontainers/viloca:1.1.0--pyhdfd78af_0 viloca run -b test_aln.cram -f test_ref.fasta
[E::cram_index_load] Could not retrieve index file for 'test_aln.cram'
Index file was created successfully.
VILOCA terminated successfully.

In general, the warning you encountered typically appears if the alignment file is empty, if the specified region contains no reads, or if the reads are too short for the local region size and are therefore excluded. However, with the provided test data, this should not occur.

As for your feature request to add an output directory option:
I agree that this would be a useful addition. However, implementing this feature would require changes to the C++ code of the tool. @DrYak, could you please provide guidance or an overview of how we might approach this?
Edit: One way to handle the output directory in the C++ code is to execute the C++ program from the new output directory using the Python script.

[charlesfoster]

Hi again,

I can confirm that when using the recent 1.2.0 release I am no longer getting any errors related to "No reads found in the requested region" with the test data, nor with my own data (provided I use a small enough -w value for short reads). The other pkg_resources text has also disappeared. Thanks!

Just one other thing of note. When running with my own BAM file, I got the following output:

Index file was created successfully.
b2w run not successful

When checking the logfile, the failure was caused by:

DEBUG 2025/07/28 18:12:12 shotgun.py: main() 497: 	Soft clipping only possible on the edges of a read.

I was a bit confused by this until I did some digging and determined that some supplementary alignments of reads apparently had internal soft clips. Might be worth documenting that supplemental alignments should be filtered out, unless this was just a quirk for me?

Cheers,
Charles

[LaraFuhrmann]

Thank you for testing the new release and reporting the issue with the supplementary alignments. We have updated the README so that other users are also aware of this.