파이썬 파일을 구성 파일로 사용하는 것이 얼마나 나쁜 생각입니까?

저는 항상 애플리케이션 구성을 위해 JSON 파일을 사용했습니다 . 나는 많은 Java를 코딩 할 때부터 사용하기 시작했으며 지금은 주로 서버 측 및 데이터 과학 Python 개발을 위해 노력하고 있으며 JSON 이 더 이상 올바른 길 인지 확실하지 않습니다 .

Celery가 구성을 위해 실제 Python 파일을 사용하는 것을 보았습니다. 처음에는 그것에 대해 회의적이었습니다. 그러나 구성에 간단한 Python 데이터 구조를 사용한다는 아이디어가 나에게 커지기 시작했습니다. 일부 전문가 :

• 데이터 구조는 일반적으로 코딩하는 것과 동일합니다. 따라서 마음의 프레임을 변경할 필요가 없습니다.
• 내 IDE (PyCharm)는 구성과 코드 간의 연결을 이해합니다. Ctrl+ B구성과 코드 사이를 쉽게 이동할 수 있습니다.
• IMO 불필요한 엄격한 JSON 으로 작업 할 필요가 없습니다 . 큰 따옴표, 후행 쉼표 및 주석이 없습니다.
• 작업중 인 응용 프로그램에서 테스트 구성을 작성한 다음 변환 및 JSON 구문 분석을 수행하지 않고도 구성 파일로 쉽게 이식 할 수 있습니다.
• 실제로 필요한 경우 구성 파일에서 매우 간단한 스크립팅을 수행 할 수 있습니다. (이것은 매우 제한적이어야하지만)

그래서 제 질문은 : 제가 바꾸면 어떻게 발을 쏠까요?

숙련되지 않은 최종 사용자는 구성 파일을 사용하지 않습니다. 구성 파일에 대한 모든 변경 사항은 현재 Git에 커밋되고 지속적인 배포의 일부로 서버에 롤아웃됩니다. 응급 상황이 발생하거나 개발 중이 아닌 한 수동 구성 변경은 없습니다.

(나는 YAML을 고려 했지만 그것에 대해 뭔가를 묻습니다. 그래서 지금은 미국 테이블에서 벗어났습니다.)

설정 파일 대신 스크립팅 언어를 사용하는 것은 언뜻보기에 훌륭 합니다. 해당 언어의 모든 기능을 사용할 수 있고 간단 eval()하거나 가능 import합니다. 실제로 몇 가지 문제가 있습니다.

• 프로그래밍 언어이므로 학습해야합니다. 구성을 편집하려면이 언어를 충분히 알아야합니다. 구성 파일은 일반적으로 형식이 단순하여 잘못하기가 더 어렵습니다.

• 프로그래밍 언어이므로 구성을 디버깅하기가 어려워 질 수 있습니다. 일반 구성 파일을 사용하면 파일을보고 각 속성에 어떤 값이 제공되는지 확인할 수 있습니다. 스크립트를 사용하면 값을 보려면 먼저 스크립트를 실행해야합니다.

• 이는 프로그래밍 언어이므로 구성과 실제 프로그램을 명확하게 구분하기가 어렵습니다. 때로는 이런 종류의 확장 성을 원하지만 그 시점에서 아마도 실제 플러그인 시스템을 찾고있을 것입니다.

• 이는 프로그래밍 언어이므로 구성에서 프로그래밍 언어로 수행 할 수있는 모든 작업을 수행 할 수 있습니다. 따라서 언어의 유연성을 크게 저하시키는 샌드 박스 솔루션을 사용하거나 구성 작성자를 신뢰하고 있습니다.

따라서 도구의 대상이 개발자 (예 : Sphinx config 또는 Python 프로젝트의 setup.py) 인 경우 구성에 스크립트를 사용하는 것이 좋습니다. 실행 가능한 구성을 가진 다른 프로그램은 Bash와 같은 쉘과 Vim과 같은 편집기입니다.

구성에 많은 조건부 섹션이 포함되어 있거나 콜백 / 플러그인을 제공하는 경우 구성에 프로그래밍 언어를 사용해야합니다. eval () 대신 스크립트를 직접 사용하면 일부 구성 필드가 더 디버깅 가능한 경향이 있습니다 (스택 추적 및 줄 번호를 생각하십시오!).

구성이 너무 반복적이어서 구성을 자동 생성하는 스크립트를 작성하는 경우 프로그래밍 언어를 직접 사용하는 것이 좋습니다. 그러나 구성에 대한 더 나은 데이터 모델은 그러한 명시 적 구성의 필요성을 없앨 수 있습니까? 예를 들어, 구성 파일에 나중에 확장 할 자리 표시자가 포함될 수 있으면 도움이 될 수 있습니다. 때때로 다른 기능은 서로 우선 순위가 다른 여러 구성 파일이 서로 무시할 수 있지만 자체 문제가있는 경우도 있습니다.

대부분의 경우 INI 파일, Java 특성 파일 또는 YAML 문서가 구성에 훨씬 적합합니다. 복잡한 데이터 모델의 경우 XML도 적용 할 수 있습니다. 앞서 언급했듯이 JSON은 훌륭한 데이터 교환 형식이지만 사람이 편집 가능한 구성 파일로 적합하지 않은 몇 가지 측면을 가지고 있습니다.

의 모든 +1 아몬의 대답 . 이것을 추가하고 싶습니다 :

다른 언어로 작성된 코드 내에서 동일한 구성을 처음 가져올 때 Python 언어를 구성 언어로 사용하는 것이 유감입니다. 예를 들어 프로젝트의 일부이며 C ++ 또는 Ruby로 작성된 코드 또는 다른 구성으로 코드를 가져와야하는 경우 Python 인터프리터에서 라이브러리로 링크하거나 Python 코 프로세스의 구성을 구문 분석해야합니다. 어색하거나 어렵거나 오버 헤드가 높습니다.

오늘이 구성을 가져 오는 모든 코드는 Python으로 작성되었을 수 있으며 내일도 이것이 사실이라고 생각할 수 있지만 확실하게 알고 있습니까?

구성에 로직 (정적 데이터 구조 이외의 다른 것)을 거의 사용하지 않을 것이라고 말했지만, 조금이라도 있으면 언두하기가 어려울 것입니다. 선언적 구성 파일로 다시 이동할 수 있습니다.

기록 편집 : 여러 사람들이 프로젝트가 다른 언어로 성공적으로 완전히 재 작성 될 가능성에 대해이 답변에 대해 언급했습니다. 완전한 이전 버전과 호환되는 다시 쓰기는 거의 볼 수 없습니다. 내가 실제로 생각한 것은 다른 언어로 작성된 동일한 프로젝트의 조각과 조각 (그리고 동일한 구성에 액세스해야 함)이었습니다. 예를 들어, 파이썬에서 속도를 높이고 배치 데이터베이스를 정리하고 일부 쉘 스크립트를 접착제로 사용하기 위해 C ++로 스택을 제공합니다. 따라서이 경우에 대해서도 생각하십시오 :)

다른 답변은 이미 훌륭합니다. 몇 가지 프로젝트에서 실제 사용 경험을 가져 오겠습니다.

찬성

그들은 대부분 이미 철자가 있습니다 :

• 파이썬 프로그램이라면 파싱은 산들 바람 ( eval)입니다. 그것은 (우리의 프로그램에, 우리는 / 덤프를 통해 잘로드 기하학적 점 및 변환,이 훨씬 더 복잡한 데이터 유형에 대해 자동으로 작동 repr/를 eval);
• 몇 줄의 코드로 "가짜 구성"을 만드는 것은 쉽지 않습니다.
• JSON보다 더 나은 구조와 IMO 방식으로 구문이 더 좋습니다 (jeez조차도 주석이 있고 사전 키를 큰 따옴표로 묶지 않아도 큰 가독성을 얻습니다).

단점

• 악의적 인 사용자는 기본 프로그램이 할 수있는 모든 것을 할 수 있습니다. 일반적으로 사용자가 구성 파일을 수정할 수 있으면 응용 프로그램이 수행 할 수있는 모든 작업을 이미 수행 할 수 있기 때문에이 문제는 많이 고려하지 않습니다.
• 더 이상 파이썬 프로그램에 없다면 문제가있는 것입니다. 우리의 구성 파일 중 일부는 원래 응용 프로그램에 대한 개인 정보로 유지되었지만 특히 하나는 여러 다른 프로그램에서 사용하는 정보를 저장하기 위해 왔으며 대부분은 현재 C ++로되어 있습니다. 파이썬의 하위 집합 repr. 이것은 분명히 나쁜 일입니다.
• 프로그램이 Python으로 남아 있어도 Python 버전을 변경할 수 있습니다. 애플리케이션이 Python 2에서 시작되었다고 가정 해 봅시다. 많은 테스트를 거친 후에 파이썬 3으로 마이그레이션했습니다. 불행히도 실제로 모든 코드를 테스트 하지는 않았습니다. 고객의 컴퓨터에 모든 구성 파일이 있고 Python 2 용으로 작성되었으며 그렇지 않은 경우 실제로 통제권이 없습니다. Python 2 인터프리터를 번들 / 호출하려는 경우가 아니면 이전 구성 파일 (파일 형식에 대해 종종 수행됨)을 읽을 수있는 "호환성 모드"를 제공 할 수 없습니다!

• 파이썬을 사용하는 경우에도 코드에서 구성 파일을 수정 하는 것은 실제 문제입니다. 코드를 수정하는 것은 결코 쉽지 않습니다. 특히 구문이 풍부하고 LISP 또는 이와 유사한 코드가 아닙니다. 우리 프로그램 중 하나는 원래 손으로 작성한 Python 구성 파일을 가지고 있지만 나중에 소프트웨어를 통해 조작하는 것이 유용하다는 것이 밝혀졌습니다 (특정 설정은 GUI를 사용하여 재정렬 하는 것이 더 쉬운 방법 의 목록입니다 ). 다음과 같은 이유로 큰 문제입니다.

  • 구문 분석 → AST → 왕복 재 작성만으로도 사소한 것이 아닙니다 (나중에 제안 된 솔루션의 절반이 "폐기, 사용하지 않음, 모든 경우에 작동하지 않음"으로 표시됨).
  • 그들이 일 했어도 AST는 너무 낮은 수준입니다. 일반적으로 파일에서 수행 된 단계가 아니라 파일에서 수행 된 계산 결과 를 조작 하는 데 관심 이 있습니다.
  • 코드를 이해하거나 조작 할 수없는 복잡한 계산에 의해 생성 될 수 있기 때문에 관심있는 값만 편집 할 수 없다는 단순한 사실을 알 수 있습니다.

  이것을 JSON, INI 또는 (God forbid!) XML과 비교하십시오. 여기서 메모리 손실 표현은 데이터 손실없이 항상 편집하고 다시 쓸 수 있습니다 (XML, 대부분의 DOM 파서는 공백을 텍스트 노드 및 주석 노드에 유지할 수 있음) 또는 적어도 일부 형식 (JSON, 형식 자체가 읽고있는 원시 데이터보다 훨씬 많은 것을 허용하지 않는)을 잃어 버립니다.

평소와 같이 명확한 해결책은 없습니다. 이 문제에 대한 현재의 정책은 다음과 같습니다.

• 구성 파일이 다음과 같은 경우 :

  • 확실히 파이썬 응용 프로그램과 개인 응용 프로그램의 경우-아무도 그것을 읽지 않습니다.
  • 손으로 쓴;
  • 신뢰할 수있는 출처에서 온 것;
  • 대상 응용 프로그램 데이터 유형을 사용하는 것은 실제로 프리미엄입니다.

  파이썬 파일 은 유효한 아이디어 일 수 있습니다.

• 대신에 :

  • 다른 응용 프로그램을 읽었을 가능성이 있습니다.
  • 이 파일은 응용 프로그램, 심지어 내 응용 프로그램 자체에서 편집 할 수 있습니다.
  • 신뢰할 수없는 출처에서 제공합니다.

  "데이터 전용"형식이 더 좋습니다.

단일 선택을 할 필요는 없습니다. 최근에는 두 가지 방법을 모두 사용하는 응용 프로그램을 작성했습니다. 멋진 Python 보너스를 얻는 이점이있는 첫 번째 설정, 필기 설정 및 UI에서 편집 된 구성을위한 JSON 파일이 거의 수정되지 않은 파일이 있습니다.

주요 질문은 구성 파일을 Python과 같은 Turing 완전한 언어로 만들고 싶 습니까? 그것을 원한다면, Guile 또는 Lua 와 같은 다른 (완전한) 스크립팅 언어를 포함시키는 것을 고려할 수도 있습니다 (Python보다 사용 또는 포함하는 것이 "간단한"것으로 인식 될 수 있기 때문에 확장 및 확장에 대한 장을 읽으십시오) Python 포함 ). ( Amon의 다른 답변 때문에 깊이 논의 했으므로) 더 이상 논의하지는 않지만 응용 프로그램에 스크립팅 언어 를 포함시키는 것이 건축 상의 주요 선택 이므로 매우 일찍 고려해야합니다.; 나는 나중에 그 선택을 권장하지 않습니다!

"스크립트"를 통해 구성 가능한 프로그램의 잘 알려진 예는 GNU emacs 편집기 (또는 독점 영역의 AutoCAD )입니다. 따라서 스크립팅을 수락하면 일부 사용자는 해당 기능을 광범위하게 사용하고 결국 남용 라인 스크립트를 작성한다는 점에 유의하십시오. 따라서 충분한 스크립팅 언어를 선택하는 것이 중요합니다.

그러나 (적어도 POSIX 시스템에서는) 초기화시 구성 "파일"을 동적으로 계산할 수있는 편리한 방법을 고려할 수 있습니다 (물론, 시스템 관리자 나 사용자에게 제정신 구성의 부담을 남겨두고 실제로는 구성입니다) 파일이나 명령에서 나오는 텍스트 ). 이를 위해 a 또는 a 로 시작하는 구성 파일 경로 가 실제로 파이프 라인으로 읽는 쉘 명령 이라는 규칙을 채택 하고 문서화 할 수 있습니다 . 따라서 사용자에게 가장 익숙한 "전 처리기"또는 "스크립트 언어"를 사용할 수 있습니다.!|

^{(동적으로 계산 된 구성을 수락하는 경우 보안 문제에 대해 사용자를 신뢰해야합니다)}

따라서 초기화 코드에서 main(예를 들어) 일부 --config 인수를 수락하고 일부 인수confarg 를 가져옵니다 FILE*configf;. 해당 인수로 시작하는 !경우 (예 : (confarg[0]=='!')....) configf = popen(confarg+1, "r");해당 파이프를 사용 하여 닫습니다 pclose(configf);. 그렇지 않으면 configf=fopen(confarg, "r");해당 파일을 사용 하고 닫습니다 fclose(configf);(오류 확인을 잊지 마십시오). 참조 파이프 (7) , 는 popen (3) , fopen을 (3) . 파이썬으로 코딩 된 응용 프로그램의 경우 os.popen 등에 대해 읽으십시오 .

^{(이상한 사용자가 위 의 트릭 을 우회 !foo.config하기 위해 전달 ./!foo.config하도록 명명 된 구성 파일을 전달하려는 문서 popen)}

BTW, 그러한 트릭은 단지 편리함입니다 (고급 사용자가 구성 파일 을 생성 하기 위해 일부 쉘 스크립트를 코딩하도록 요구하지 않기 위해 ). 사용자가 버그를보고하려면 생성 된 구성 파일을 보내야 합니다.

초기화시 플러그인 을 사용하고로드하는 기능 ( 예 : dlopen (3)) 을 사용하여 응용 프로그램을 설계 할 수도 있습니다 (그리고 해당 플러그인에 대해 사용자를 신뢰해야 함). 다시 말하지만 이것은 매우 중요한 아키텍처 결정입니다 (그리고 이러한 플러그인과 애플리케이션에 대해 다소 안정적인 API 와 규칙 을 정의 하고 제공 해야합니다).

Python과 같은 스크립팅 언어로 코딩 된 애플리케이션의 경우 eval 또는 exec 또는 이와 유사한 프리미티브에 대한 일부 프로그램 인수를 승인 할 수도 있습니다 . 다시 보안 문제는 (고급) 사용자 의 관심사입니다 .

구성 파일의 텍스트 형식에 관한 것은 (그것이 생성 여부를 수), 나는 당신이 주로 필요가 있다고 생각 을 문서화 아니라 (일부 특정 형식의 선택입니다 하지 중요, 나는 수 있도록하는 것이 좋습니다 그러나 사용자가 넣을 수 그 안에 약간의 코멘트가 있습니다). JSON (바람직하게는 //eol 또는 /*... 까지 평소와 같이 주석을 수락하고 건너 뛰는 일부 JSON 파서와 함께 */) 또는 YAML, XML, INI 또는 자신의 것을 사용할 수 있습니다. 구성 파일을 구문 분석하는 것은 상당히 쉽습니다 (해당 작업과 관련된 많은 라이브러리가 있습니다).

amon의 답변에 추가하여 대안을 고려 했습니까? JSON이 필요한 것 이상일 수도 있지만 Python 파일은 위에서 언급 한 이유로 앞으로 문제가 발생할 수 있습니다.

그러나 파이썬에는 이미 모든 요구를 충족시킬 수있는 매우 간단한 구성 언어에 대한 구성 파서가 있습니다. 이 ConfigParser모듈 은 간단한 구성 언어를 구현합니다.

TCL로 작성된 구성 파일이있는 잘 알려진 소프트웨어 로 오랫동안 일해 왔으므로 아이디어는 새로운 것이 아닙니다. 언어를 모르는 사용자는 단일 set name value명령문을 사용하여 간단한 구성 파일을 작성 / 편집 할 수있는 반면, 고급 사용자와 개발자는이를 사용하여 정교한 트릭을 가져올 수 있기 때문에 이것은 매우 효과적이었습니다 .

"구성 파일을 디버깅하기 어려울 수있다"는 것이 유효한 문제라고 생각하지 않습니다. 응용 프로그램에서 사용자가 스크립트를 작성하도록 강요하지 않는 한 사용자는 항상 구성 파일에서 간단한 할당을 사용할 수 있습니다. 이는 JSON 또는 XML에 비해 제대로하기가 훨씬 어렵습니다.

구성을 다시 작성하는 것은 문제가되지만 그다지 좋지는 않습니다. 임의의 코드를 업데이트하는 것은 불가능하지만 파일에서 구성을로드하여 변경 한 후 다시 저장하는 것은 불가능합니다. 기본적으로 읽기 전용이 아닌 구성 파일에서 일부 스크립팅을 수행하면 set name value일단 저장되면 동등한 명령문 목록으로 끝납니다 . 이것이 일어날 것이라는 힌트는 파일의 시작 부분에 "편집하지 마십시오"라는 주석입니다.

고려해야 할 한 가지 사항은과 같은 간단한 정규식 기반 도구로 구성 파일을 안정적으로 읽을 수는 sed없지만 현재 JSON 파일의 경우가 아니라는 점을 이해하면 잃어 버리지 않습니다.

구성 파일을 실행할 때 적절한 샌드 박싱 기술 을 사용 하십시오.

여기에 다른 좋은 답변의 모든 유효한 포인트 (와우, 심지어 Turing-complete 개념을 언급 했음) 외에도 실제로 Python 파일을 사용하는 경우에도 Python 파일을 구성으로 사용하지 않는 몇 가지 확실한 실제 이유가 있습니다. 프로젝트 만.

1. Python 소스 파일의 설정은 기술적으로 읽기 전용 데이터 파일이 아닌 실행 가능한 소스 코드의 일부입니다. 이 경로를 이동하는 경우, 당신이 할 일반적 것 import config"편리 성"의 종류는 아마도 사람들이 처음에 설정으로 파이썬 파일을 사용하여 시작하는 가장 큰 이유 중 하나 때문에. 이제 config.py를 리포지토리에 커밋하는 경향이 있습니다. 그렇지 않으면 최종 사용자가 처음으로 프로그램을 실행하려고 할 때 혼란스러운 ImportError가 발생합니다.

2. 실제로 해당 config.py를 리포지토리에 커밋한다고 가정하면 팀 구성원은 다른 환경에서 다른 설정을 갖게 될 것입니다. 언젠가 어떤 회원이 실수로 자신의 로컬 구성 파일을 저장소에 커밋 한다고 상상해보십시오 .

3. 마지막으로 프로젝트는 구성 파일에 비밀번호를 가질 수 있습니다. (이것은 그 자체로 논란의 여지가 있지만 어쨌든 발생합니다.) 그리고 구성 파일이 저장소에 있으면 자격 증명을 공개 저장소에 넣을 위험이 있습니다.

이제 범용 JSON 형식과 같은 데이터 전용 구성 파일을 사용하면 위의 세 가지 문제를 모두 피할 수 있습니다. 사용자에게 자신의 config.json을 제안하여 프로그램에 제공하도록 합리적으로 요구할 수 있기 때문입니다.

추신 : JSON에는 많은 제한이 있다는 것이 사실입니다. OP가 언급 한 한계 중 2 가지는 창의력으로 해결할 수 있습니다.

• JSON 파일에 주석을 넣는 방법 (적절하게)

• 그리고 보통 후행 쉼표 규칙을 무시할 자리 표시자가 있습니다. 이처럼 :

  {
      "foo": 123,
      "bar": 456,
      "_placeholder_": "all other lines in this file can now contain trailing comma"
  }