### 0.0.1 Python 가상 환경(venv) 격리 및 requirements.txt를 통한 모듈 충돌 방지
현대 PX4 빌드 아키텍처에서 가장 예민하게 부러지는 유리 턱은 바로 Python 의존성 트리다. PX4는 메타코드 제너레이션, MAVLink 패킷 룰 생성, 파라미터 메타데이터 추출, 심지어 SITL 구동에 이르기까지 전방위로 Python 스크립트를 남용 수준으로 호출한다. 이때 호스트 OS의 글로벌 Python 패키지 공간에 모듈을 마구 섞어 쓰다 보면 치명적인 **‘모듈 버저닝(Versioning) 충돌’**이 터지고 만다. 이 파국을 막기 위한 방파제가 바로 가상 환경(venv)의 적극성 도입이다.
Global Environment의 비극과 의존성 지옥
과거 혹은 비숙련 개발자들은 sudo pip3 install -r requirements.txt 명령을 무심코 휘둘러 리눅스 전체 시스템 공간 공간(/usr/lib/python3/…)을 오염시킨다. ROS2 데몬 구동용 파이썬 라이브러리, TensorFlow 학습용 모듈, PX4용 템플릿 엔진(jinja2, empy>3.3)이 한 공간에서 엉키다 보면, 어느 날 “ModuleNotFoundError” 혹은 “Version Conflict” 아비규환의 블루스크린(에러 화면)을 보게 된다. 특히 empy 패키지의 메이저 버전 차이(예: v3 vs v4)는 PX4 자동 생성 로직을 완전히 박살 낸다.
Virtual Environment(venv)의 격리 기동
진정한 엔지니어는 자신의 운영체제 생태계를 보존해야 한다.
- 가상 영역 생성: 프로젝트 루트나 시스템 보조 폴더에
python3 -m venv .venv명령으로 순결한 플라스틱 격리 상자를 만들어 낸다. - 공간 활성화:
source .venv/bin/activate명령으로 셸의 접근 포인터를 이 상자 안으로 비틀어 넣는다. - 격리 주입: 이 상태에서
pip install -r Tools/setup/requirements.txt를 구동하면, 오직 PX4만이 목숨을 걸고 요구하는 특정 모듈의 버전 록(Version Lock) 데이터들이 이 플라스틱 상자 안에만 고립되어 박힌다.
빌드 시스템인 CMake 역시 매우 똑똑하여, 활성화된 가상 환경을 탐지하면 호스트 OS의 더러운 글로벌 파이썬 인터프리터를 버리고 이 venv 내부의 인터프리터를 1순위 타겟으로 물고 들어간다. 이 극강의 아이솔레이션(Isolation) 전략이야말로, 하나의 PC에서 ROS2 노드 프로그래밍과 PX4 펌웨어 컴파일을 평화롭게 공존시키는 유일한 생존 비급이다.