Getting AFNI version in a simpler way

[mrneont]

Summary

Avoid crashes due to AFNI version parsing, by using a better option to get the version number directly.

Actual behavior

afni --version in nipype/interfaces/afni/base.py gives a complicated string (Precompiled binary linux_ubuntu_16_64_glw_local_shared: Mar 23 2023 (Version AFNI_23.0.07 'Commodus')), that parse_version(raw_info) in the same file doesn't appear to always parse correctly.

Expected behavior

afni -vnum would just give the version in the format AFNI_23.0.07, which could be simply parsed for just the numerical-with-dots part. It should also be platform independent.

How to replicate the behavior

Current behavior apparently causes a crash in MRIQC: https://github.com/nipreps/mriqc/issues/1087

Script/Workflow details

Please put URL to code or code here (if not too long).

Platform details:

Execution environment

Choose one

• Container [Tag: ???]
• My python environment inside container [Base Tag: ???]
• My python environment outside container

[effigies]

Thanks, Paul, that's really handy. I guess we need a try/catch, because if I try that with the latest available on NeuroDebian:

$ afni -vnum
Precompiled binary Debian-x86_64-1-gnu: May 17 2018 (Version Debian-18.0.05+git24-gb25b21054~dfsg.1-1~nd17.10+1+nd18.04+1)

Thanks go to S Japee for caloric input

Initializing: X11Error: Can't open display: 
++ AFNI is detached from terminal.

I suspect what's going on with that user is that they've patched /usr/bin into their singularity container and are running into either a FileNotFound or a dynamic linking failure.

[afni-rickr]

That is a complication. Paul added that -vnum option in Oct 2019, after that Debian version was released.

[mrneont]

Ah, indeed. May, 2018 seems like so long ago...