지난주 미생물 유전체 분석 워크샵을 실시하면서 실제 현장에서 맞닥뜨릴 컴퓨터 활용 환경이 제각각이라는 것을 깨닫게 되었다. 심지어 정부 조직에 속하는 어느 연구소에서 온 사람의 말을 들어보니 sudo 명령을 쓰려면 상급 부서의 허가를 받아야 한다는 것이었다. 쉽게 말해서 'sudo apt install <package>' 명령을 실행하기 어렵다는 뜻이다.
그렇다면 유전체 분석에 필요한 모든 프로그램을 일반 관리자 권한으로 다룰 수 있는 conda로 설치해야 된다는 뜻이 된다. 교육을 위해서 내가 구축한 환경은 WSL에 우분투(+실습에 필요한 애플리케이션)를 설치하여 테스트를 거친 후 tar로 export한 것이었으니 누구나 다 자기가 사용하는 PC 또는 노트북 컴퓨터에 'wsl --import <배포> tar_file' 명령으로 이를 설치하면 된다. 또는 KRIBBuntu-focal 2205 distro 제작 및 재설치 과정 문서를 참조하여 tar 파일의 도움 없이 직접 자기 컴퓨터에 실습을 위한 환경을 만들어도 된다. 일부 프로그램은 conda를 이용하였지만, environment에 무관하게 골고루 쓰이는 유틸리티는 sudo 권한으로 dep 패키지를 깔았다. 이렇게 조성한 환경에서 박테리아 유전체 몇 개를 조립하는 정도의 일은 별 어려움이 없이 진행할 수 있다. 그러나 진핵 생물의 유전체를 조립하려면 '서버'라고 이름을 붙일만한 수준의 컴퓨터에 프로그램을 설치해야 한다.
만약 그러한 서버급 컴퓨터에서 일반 사용자의 권한만 가진 상태에서 이번 교육의 실습 내용을 재현해 보려면 어떻게 해야 하는가? 'sudo apt install <package>'를 'conda install <package>'로 대체해야 되는데, 이것이 완벽하게 대응하지는 않는다.
예를 들어 매우 널리 쓰이는 long read assembler인 canu의 예를 들어보자. 오늘 'sudo apt info canu' 명령으로 확인해 보니 canu 1.9+dfsg-1build1 버전이 deb 패키지로 제공되기는 한다. 그런데 덩달아 깔리는 dependency가 무려 462개라고 나온다. 어차피 sudo를 쓰지 않고 canu를 설치하기로 했으니 다른 방법을 알아 보아야 한다. 기본 환경은 conda base environment라고 가정하자.
만약 이미 만들어진 canu binary를 수동으로 설치한다면? 설치 후 실행을 해 보니 libgomp.so.1 라이브러리를 찾지 못한다.
$ canu --version /home/kribb/apps/canu-2.2/bin/sqStoreCreate: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory
'export LD_LIBARAY_PATH=~/miniconda3/lib/'를 먼저 실행해야 canu가 제대로 실행되었다. 만약 conda를 이용하여 canu 패키지를 설치했다면(v2.2), 구동에 필요한 라이브러리의 위치를 제대로 인식하고 있으므로 문제가 생기지 않는다.
Canu를 소스로부터 빌드한다면? Canu GitHub 사이트에서는 별로 권장하지 않는다. 안 될 일이 뭐가 있겠는가? 시도를 해 보니 에러 잔치가 벌어졌다. WSL에 우분투를 설치한 직후에는 프로그램 개발을 위한 환경이 일절 갖추어져 있지 않다. 무엇이 더 필요한가? Conda를 이용하여 설치할 수 있는 의존성을 하나씩 헤아려 보았다. make, gcc, gxx(g++이 여기에 있다), binutils(ar)... 이것을 conda base environment에만 둔다고? 별도의 관리자가 있는 상식적인 수준의 리눅스 서버 컴퓨터라면 이미 시스템 차원에 설치가 되어 있을법한 프로그램들이다.
Canu의 설치 방법에 이렇게 열을 올렸던 이유는, 바로 circlator(pip로 설치; v1.5.5)에서 canu의 버전을 제대로 인식하지 못하는 문제가 발생했기 때문이다. 이는 이미 canu GitHub 사이트에서 여러 차례 제기된 이슈였다. Conda로 설치하는 circlator(역시 v1.5.5)도 마찬가지였다.
$ circlator progcheck Circlator version: 1.5.5 External dependencies: bwa 0.7.17 /home/kribb/miniconda3/bin/bwa Found canu but couldn't get version. nucmer 3.1 /home/kribb/miniconda3/bin/nucmer prodigal 2.6.3 /home/kribb/miniconda3/bin/prodigal samtools 1.15.1 /home/kribb/miniconda3/bin/samtools WARNING: SPAdes version 3.15.5 is being used. It will work, but better results are usually obtained from Circlator using SPAdes version 3.7.1. Although 3.7.1 is not the latest version, we recommend it for Circlator. spades 3.15.5 /home/kribb/miniconda3/bin/spades.py Python version: 3.8.12 | packaged by conda-forge | (default, Jan 30 2022, 23:42:07) [GCC 9.4.0] Python dependencies: openpyxl 3.0.10 /home/kribb/miniconda3/lib/python3.8/site-packages/openpyxl/__init__.py pyfastaq 3.17.0 /home/kribb/miniconda3/lib/python3.8/site-packages/pyfastaq/__init__.py pymummer 0.11.0 /home/kribb/miniconda3/lib/python3.8/site-packages/pymummer/__init__.py pysam 0.19.0 /home/kribb/miniconda3/lib/python3.8/site-packages/pysam/__init__.py
가장 적극적인 해결 방법은 external_progs.py의 특정한 라인을 다음의 [1]에서 [2]로 고치는 것이다. 아무리 보아도 [2]가 더 합리적이다.
[1] 'canu': ('-version', re.compile(r'^Canu \D*([\d][\d\.]+)')),
[2] 'canu':('-version', re.compile(r'canu ([\d+\.\d+[\.\d]*)')),
'삽질'을 거듭하면서 circlator의 바람직하지 않은 행동에 대한 확실한 정보를 얻게 되었다. Circlator는 long read assembler로서 canu 또는 spades(default; v3.7.1을 선호하지만 너무 오래되었음) 중의 하나를 필요로 한다. 현재 $PATH에 canu와 spades가 전부 존재한다면 '--assembler {canu, spades}' 인수로 특별히 지정하지 않는 이상 spades를 이용한다. 따라서 기본 조건에서는 circlator가 문제 없이 실행된다. 그러나 canu의 버전을 제대로 인식하지 못하는 상태에서는 '--assembler canu' 조건을 주면 circlator가 에러를 발생한다.
애플리케이션마다 요구하는 조건이 모두 다르므로, 최적의 실행을 위해서는 환경이 자꾸만 파편화된다. 관리도 어렵고, 발생하는 에러에 대해서 개별적으로 대처해야 한다. Conda 환경이 그 수고를 크게 덜어주는 것은 사실이지만, 기록을 해 놓지 않으면 내가 특정 프로그램을 'conda(또는 mamba) install'로 깔았는지, 또는 pip로 깔았는지 기억하기가 어렵다. 덕지덕지 땜질한 상태에서 프로그램을 사용하다가 특정 파이썬 라이브러리를 임의로 삭제하면 환경이 꼬이기 시작한다. 어쩌면 파편화의 단점을 감수하고서라도 중요 애플리캐이션에 대해서 환경을 독립시켜 두는 것이 바람직할 수도 있다. 꼬인 환경은 싹 지운 뒤 다시 만들면 되기 때문이다.
댓글 없음:
댓글 쓰기