config_script 재작성

이 컴퓨터 저 컴퓨터 옮겨가면서 작업할 때, 컴퓨터별로 환경을 통일하는 작업은 귀찮은 일이다. 그래서 나는 이런 스크립트를 만들어서 써왔다. 아직 사용하는데 큰 문제는 없었지만, 그때그때 필요한 기능들을 넣다 보니 스크립트가 난잡해지고, 내가 다른 프로젝트에서 작업할 때 자주 사용하지 않는 bash를 이용해서 만들다 보니 수정이 필요해서 코드를 다시 볼 때, 익숙하지 않아서 실수하는 문제가 생겼다. 그래서 이번 연휴를 맞아서 스크립트를 완전히 새로 작성하였다.

이번에 작업에서 초점을 맞춘 부분은 크게 2가지였다. 첫 번째는 시간이 지나도 알아보기 쉽도록 익숙한 언어로 작업할 것, 두 번째는 수정이 필요하거나 새로운 일이 추가될 때 확장하기 쉽도록 하는 것이었다.

첫 번째 요구사항을 맞추기 위하여 작업은 python을 이용하였다. 어차피 하는 대부분 작업이 조건에 맞추어 파일을 옮기고 command를 실행시키는 일들뿐이고 복잡한 일은 없어서 언어는 무엇을 사용해도 상관없어 보였기에 그중에 가장 익숙한 python을 이용했다.

두 번째 요구사항을 맞추기 위하여 기존의 스크립트를 분석해 보니 대부분의 일이

1. 본 작업에 앞서 사전작업을 한다.
2. 작업해야 할 파일 리스트에서 하나씩 꺼내서
1. source가 있는지 파악하여 에러처리를 하고
2. destination에 이미 파일이 존재하는지 확인하여 에러처리를 하고
3. source를 destination으로 복사/링크 등을 한다.
3. 본 작업이 끝난 뒤 마무리 작업을 한다.

의 순서로 진행되었다.

그래서 Config라는 abstract class를 만들고, 각각의 단계에 맞춰서

1. pre()
1. source_exists()
2. resolve_conflict()
3. do()
2. post()

의 5개의 abstract method를 만들어 원하는 작업마다 Config를 상속받는 class를 만들어 상황에 맞게 위의 method들을 override 하는 방식으로 작업을 진행하였다. 또한, source_exists/resolve_conflict/do 함수 안에서 공통으로 쓰이는 함수들인 소스의 경로를 알아오는 source_dir/source_path, 목적지의 정보를 알아오는 destination_dir/destination_path, conflict 시 backup 할 경로를 알아오는 backup_path를 override 가능한 함수로 만들었다. 이렇게 해서 특정 경로에서 특정 경로로 symbolic link를 만드는 작업을 할 때는 경로만 재정의하여 사용할 수 있도록 하였다.

그래서 나온 결과물의 class hierarchy는 위와 같다.

다음 작업으로 고려하고 있는 것은 맥이나 윈도에서의 환경세팅과 rvm/npm/pip/virtualenv 등 작업에 필요한 일부 패키지들을 직접 컴파일해서 사용할 수 있도록 하는 것이다. 하지만 당장은 하지 않을 것 같고 조만간에 시간이 나면 더 작업할 것 같다.