pangolin --all-versions error on fatovcf

[GLTOhorsman]

Good morning @AngieHinrichs !

do you know if the pangolin-data version commits to pangolin for pangolin-data v.1.31, or another element of #440 and #467 (comment)

could be causing an issue when checking pangolin --all-versions

faToVcf returned non-zero exit status 1

pangolin: 4.3.1
pangolin-data: 1.31

[GLTOhorsman]

Traceback (most recent call last):
  File {...}bin/pangolin", line 8, in <module>
    sys.exit(main())
  File {...}lib/python3.8/site-packages/pangolin/command.py", line 160, in main
    print_versions_exit(config)
  File {...}lib/python3.8/site-packages/pangolin/utils/initialising.py", line 242, in print_versions_exit
    print_faToVf_version()
  File {...}lib/python3.8/site-packages/pangolin/utils/initialising.py", line 209, in print_faToVf_version
    output = subprocess.run("faToVcf -verbose=2 -h 2>&1 | grep '#'", shell=True, check=True,
  File {...}lib/python3.8/subprocess.py", line 516, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command 'faToVcf -verbose=2 -h 2>&1 | grep '#'' returned non-zero exit status 1.

[GLTOhorsman]

seeing this pull #553

[AngieHinrichs]

They pangolin and pangolin-data pulls should not affect faToVcf, but there was a recent usher release that changed the faToVcf binary come to think of it. Can you run faToVcf with no options and copy-paste the output here? Thanks. Meanwhile I will try to figure out what changed in usher 0.6.4.

[GLTOhorsman]

faToVcf
faToVcf: error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory
which libssl.so.3
: no libssl.so.3 in {...}

i've pinned usher to 0.6.3 here and it seems to report back that 0.6.3 is installed. I'll dig around to see if something shifted on my end, or if the more recent versions do not accept my pinned dependencies

[GLTOhorsman]

with mine limits, i was looking for usher>=0.6.2 and so far mamba won't be able to find https://github.com/yatisht/usher/releases/tag/v0.6.4 on channels:

• conda-forge
• bioconda

i can switch to pip the github repo. As a head's up, the pre-release label is still up for 0.6.4

[AngieHinrichs]

Thanks, I see now that usher 0.6.4 isn't in bioconda yet so it's not the cause, sorry about the red herring. Just to make sure, did you run faToVcf in the same conda environment in which you run pangolin? In that environment, can you send the output of these commands?

conda list openssh
which faToVcf
ldd `which faToVcf` | grep ssl

For example, this is the output that I get from those commands:

conda list openssh
# packages in environment at /cluster/home/angie/miniconda3/envs/pangolin:
#
# Name                    Version                   Build  Channel
openssh                   9.6p1                h2d3b35a_0    conda-forge

which faToVcf
~/miniconda3/envs/pangolin/bin/faToVcf

ldd `which faToVcf` | grep ssl
        libssl.so.3 => /cluster/home/angie/miniconda3/envs/pangolin/bin/../lib/libssl.so.3 (0x00007f11e539b000)

So my pangolin environment has version 9.6p1 of the openssh package (from usher's environment.yml which includes openssh with no version constraints), and the pangolin environment's faToVcf gets libssl.so.3 from the pangolin environment's lib directory as expected.

[GLTOhorsman]

conda list openssh
# packages in environment at {pangolin env}:
#
# Name                    Version                   Build  Channel
openssh                   9.1p1                h2baec63_1    conda-forge

which faToVcf
... envs/{pangolin env}/bin/faToVcf

ldd $(which faToVcf) | grep ssl
libssl.so.3 => not found
	libssl.so.1.1 => {pangolin env}/bin/../lib/./libssl.so.1.1 (0x00007f3a469a3000)

[GLTOhorsman]

if i explicitly add

- openssh>=9.6p1=h2d3b35a_0
- pysam==0.16.0.1

as a dependency, my previous pin on pysam==0.16.0.1 runs into an error.

[GLTOhorsman]

unpinning pysam allowed the build to execute, with the resulting

pysam                     0.22.1           py38h2d19e03_2    bioconda

[AngieHinrichs]

That's great! So is it all working for you now? Sounds like we may need to constrain the version of openssh.

[GLTOhorsman]

since https://github.com/cov-lineages/pangolin/blob/master/environment.yml
isn't setting a required version of pysam, it may just be a me-issue artificially delaying other dependencies. Interesting to notice when it begins to conflict with updates to faToVcf though. Happy to close here