VRS in a Box

[melissacline]

Submitter Name

Melissa Cline

Submitter Affiliation

UC Santa Cruz Genomics Institute

Project Details

For a user with moderate UNIX skills, installing vrs-python is easy, but installing the dependencies (SeqRepo REST API, UTA, etc) can get involved. The goal of this project is to produce a deliverable that encapsulates vrs-python and its dependencies for a one-step installation process. This should reduce the barrier to entry to vrs-python by making it easier for new users to get started.

Required Skills

Enthusiasm
python
docker

[larrybabb]

Here's a great starting "setup" document from Kyle, Kori and Terry.

[korikuzma]

I love the Enthusiasm required skill.

[theferrit32]

In 2025-05-28 think tank session we discussed improving the usability of vrs-python by:

• Including Dockerfiles and other scripts from https://github.com/ehclark/vrs-in-a-box into the vrs-python repository.
  • Build these specialized datasets and container images. For those datasets which are small enough to include directly in a docker image (TBD, but maybe under 1-2GB) push them to a repository in Docker Hub under the ga4gh org.
• Ensure there are demos and container support for all the VCF annotator options. Ensure these are also supported by the WDL VCF Annotator task, and possibly add other workflow examples such as NextFlow and CWL. (Is this in scope, do we want to maintain this?)

We also discussed the need to define the scope of this "VRS in a Box" concept. For people who can run Docker images and only need grch37/38 I think this may be met by just copying the images from https://hub.docker.com/u/eugene75 to a ga4gh repository.

A number of other issues were also created in https://github.com/ehclark/vrs-in-a-box/issues

[egchristensen]

Several issues related to this ticket were created as part of the last think tank:

• “Review kluge code for Biocommons expert review” ehclark/vrs-in-a-box issue #2
• “Add Dockerfile to vrs-python (aka integrate vrs-in-a-box to vrs-python)” ehclark/vrs-in-a-box issue #3
• “add entry to ga4gh docker hub” ehclark/vrs-in-a-box issue #4
• “document docker hub readme” ehclark/vrs-in-a-box issue #5
• “Define precise scope of vrs-in-a-box (test and document)” ehclark/vrs-in-a-box issue #6
• “explore all the vcf-annotator options” ehclark/vrs-in-a-box issue #7
• “Provide a NextFlow workflow” ehclark/vrs-in-a-box issue #8
• We also floated the idea of packaging vrs-python in bioconda to make “VRS in a Box” more accessible to users. See ga4gh/vrs-python issue #553.

[egchristensen]

Time during this think tank was spent mainly on these issues:

• “Review kluge code for Biocommons expert review” Review kluge code for Biocommons expert review ehclark/vrs-in-a-box#2
  • Partially complete. We need to flesh out the data proxy health check in dataproxy.py
• “Add Dockerfile to vrs-python (aka integrate vrs-in-a-box to vrs-python)” Add Dockerfile to vrs-python (aka integrate vrs-in-a-box to vrs-python) ehclark/vrs-in-a-box#3
• “explore all the vcf-annotator options” explore all the vcf-annotator options ehclark/vrs-in-a-box#7

[theferrit32]

Today we can focus on finishing the dataproxy.py healthcheck method, and if there's time we can integrate the vrs-python Dockerfile and maybe set up automated builds.

I would lean towards closing the "explore all vcf-annotator options" issue. I believe this was related to wdl/cwl workflows and I think this is outside the scope our of work.

[theferrit32]

2025-07-23

We discussed making the filesystem and REST dataproxy in vrs-python have the same failure mode at startup, so that they are consistent. The filesystem dataproxy raises an exception when constructed if the directory does not exist or any files in it that it tries to open (sqlite dbs) do not exist. The REST one should work somewhat the same way in that if you pass in a URI that cannot be opened it should raise an exception. The below PR is in progress to address this.
ga4gh/vrs-python#569

In terms of merging files from the spring hackathon into vrs-python, we are still brainstorming the best way to organize that and what should be included in vrs-python vs be pointed to elsewhere.
ga4gh/vrs-python#571

One thing we definitely do want is a Dockerfile which provides an image with the vrs-python codebase that can be used to run the vrs-annotate CLI.
ga4gh/vrs-python#570
We need to get permissions in the ga4gh Docker Hub organization to create repositories, or for repositories to be created for us and us to be granted write/admin privileges to those repositories. https://hub.docker.com/u/ga4gh. Once we have that we can create GitHub actions to automatically build and publish images for each release.

I think there's general agreement that it also makes sense to include the scripts which build the slimmed down seqrepo databases in vrs-python as well.
https://github.com/ga4gh/vrs-python/tree/feature/vrs-in-a-box

[theferrit32]

We now have permission to push new images into the dockerhub ga4gh namespace, so this should be prioritized for next session.
ga4gh/vrs-python#570

I propose we build a code-only vrs-python image, then push two additional images which are layered on top of that image which add small seqrepo snapshots, one grch37 and one grch38. So 3 images. Possibly all to the same repo, using tags to refer to specific images and ensure people get the one they want.

Ideally these builds should be automated in the vrs-python github actions. It may be pretty simple as long as the grch37 and grch38 seqrepo builds do not take too long. Otherwise we may need to get creative with caching data files.

1.
ga4gh/vrs-python:2.1.3-base
ga4gh/vrs-python:latest
ga4gh/vrs-python:latest-base
2.
ga4gh/vrs-python:2.1.3-grch37
ga4gh/vrs-python:grch37
3.
ga4gh/vrs-python:2.1.3-grch38
ga4gh/vrs-python:grch38