KRIBBuntu-focal_2207 제작 완료 및 공개

2022년 8월이 다 지나가는데 버전 2207이라니 부끄럽기만 하다. 7월에 만든 배포(distro)에 사소한 문제가 있어서 이를 어제 수정하였고, export와 import를 거쳐 이상이 없음을 확인한 다음, 구글 드라이브에 올려서 공개형태로 전환하였다(xz 포맷으로 압축한 KRIBBubtu-focal_2207의 구글 드라이브 링크). 제작 과정에 대한 상세한 설명은 다음의 위키 페이지에 나온다.

KRIBBuntu-focal_2205 distro 제작 및 재설치 과정 

위키 페이지 타이틀은 버전 2205(a)에 관한 것처럼 보이지만, 버전 2207를 만드는 과정이 포함되었다. KRIBBuntu-focal_2207에서 실행할 수 있는 미생물 유전체 분석 명령어 모음은 여기(엑셀 파일)에 있다. 파일 이름이 percent encoding 상태라서 보기에 좋지 않다. 엑셀 파일의 원래 이름은 '실습용_명령어_모음_220726_.xlsx'이다. 도쿠위키(DokuWiki)에서 한글로 표시된 URL 또는 파일명을 의도한 대로 표시하려면 어떻게 해야 될런지... 위키 엔진의 문제인지 혹은 접속에 사용하는 웹브라우저의 설정 문제인지 나도 잘 모르겠다.

정작 KRIBBuntu가 무엇인지는 제대로 설명하지 않았다. KRIBBuntu란, Linux용 Windows 하위 시스템(Windows Subsystem for Linux, 줄여서 WSL이라 부름)에서 돌아가도록 만든 우분투 기반의 배포이다. 'focal'이란 Focal Fossa, 즉 우분투 20.04LTS를 기반으로 했음을 의미한다. KRIBBuntu를 만든 목적은 올해 세 차례 진행했던 미생물 유전체 분석 실습 때문이었다. 일반적인 데스크탑이나 노트북 컴퓨터에 부담 없이 설치하여 NGS read(short, long, short + long hybrid)의 조립과 평가, 조립물에서 추출한 16S rRNA 염기서열에 대한 분석, ANI 분석 등을 실시하는 것이 목표였고, 명령어 모음에서는 꽤 수준 높은(?) Bash shell script 작성 기법을 소개하기도 하였다.

Conda에 크게 의존하고 있지만 버전 2207에서는 mamba도 조금씩 사용하였다. Dependency를 면밀하게 검토하여 conda package를 빠르게 설치하는 데에는 conda보다 mamba가 월등한 것 같다. 버전 2207을 만들 때에는 sudo 명령어를 쓰지 않았다. 왜냐하면 리눅스 서버를 오직 일반 사용자 권한으로만 써야 하는 사람도 있기 때문이다. KRIBBuntu-focal_2207을 WSL에 설치하는 설명(별로 친절하지는 않음, 죄송...)을 잘 참조한다면, 본격적인 리눅스 서버에 미생물 유전체 분석용 응용 프로그램을 설치하는데 도움을 받을 수 있을 것이다.

버전 2207은 최근 구입한 ThinkPad E14 G3(AMD Ryzen 7 Mobile 5700U, 16GB memory, Windows 11)에서 테스트를 완료하였다. 버전 2205에는 포함하지 않았던 canu assembler와 prokka를 넣었다는 것도 크게 달라진 점이다. 단, canu를 돌리려면 시간이 많이 걸리고, WSL용 메모리도 넉넉하게 확보해야 한다. 아마 기본 설정은 시스템에 설치된 물리적 메모리의 50%일 것이다.

버전 2207에 각종 응용 프로그램을 설치하면서 극복해야 할 문제가 상당히 많았었다. 이를 위키 문서에 상세하게 소개한다면 직접 프로그램을 개별적으로 설치해 보려는 사람들(WSL이 되었든 진짜 리눅스 데스크탑이 되었든)에게 도움이 될 것이다. 내가 계속 게으름을 발휘한다면 문서 업데이트에 너무 몰두하지 말고 그저 xz 압축 파일을 가져다가 활용하라고 유도하게 될 것이다.

Circlator가 canu assembler 버전을 제대로 인식하지 못하는 문제

지난주 미생물 유전체 분석 워크샵을 실시하면서 실제 현장에서 맞닥뜨릴 컴퓨터 활용 환경이 제각각이라는 것을 깨닫게 되었다. 심지어 정부 조직에 속하는 어느 연구소에서 온 사람의 말을 들어보니 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)도 마찬가지였다.

• #113 Canu version is not being detected properly
• #115 canu version

다음은 'circlator procheck' 실행 때 나타나는 에러 메시지이다. 

$ 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로 깔았는지 기억하기가 어렵다. 덕지덕지 땜질한 상태에서 프로그램을 사용하다가 특정 파이썬 라이브러리를 임의로 삭제하면 환경이 꼬이기 시작한다. 어쩌면 파편화의 단점을 감수하고서라도 중요 애플리캐이션에 대해서 환경을 독립시켜 두는 것이 바람직할 수도 있다. 꼬인 환경은 싹 지운 뒤 다시 만들면 되기 때문이다.