Python 애플리케이션을 위한 가장 좋은 프로젝트 구조는 무엇인가?

Python 애플리케이션을 위한 가장 좋은 프로젝트 구조는 무엇인가?

닫혔어. 이 질문은 더 많은 것이 필요해.집중적인그것은 현재 답을 받아들이고 있지 않다.

---

이 문제를 개선하고 싶으십니까?이 게시물을 편집하여 한 가지 문제에 초점을 맞추도록 질문을 업데이트하십시오.

5년 전에 문을 닫았다.

이 질문 개선

Python에서 독점적이지 않은 최종 사용자 데스크톱(웹이 아님) 애플리케이션을 개발하려고 한다고 상상해 보십시오.프로젝트의 폴더 계층 구조를 구성하는 가장 좋은 방법은?

유지보수의 용이성, IDE 친화성, 소스 제어 분기/머그에 대한 적합성, 설치 패키지 생성 용이성 등이 바람직한 특징이다.

특히:

1. 출처를 어디에 두느냐?
2. 응용 프로그램 시작 스크립트를 어디에 두십니까?
3. IDE 프로젝트는 어디에 두십니까?
4. 단위/수락 테스트는 어디에 두십니까?
5. 구성 파일과 같은 비 Python 데이터는 어디에 저장하십니까?
6. pyd/so 바이너리 확장 모듈용 C++와 같은 비 Python 소스를 어디에 두십니까?

별로 중요하지 않다.너를 행복하게 하는 것은 무엇이든지 효과가 있을 것이다.Python 프로젝트는 간단할 수 있기 때문에 어리석은 규칙은 많지 않다.

• /scripts또는/bin그런 종류의 명령줄 인터페이스용
• /tests시험 삼아
• /libC 언어 라이브러리를 위한
• /doc대부분의 문서에는
• /apidocEpydoc에서 생성한 API 문서용.

그리고 최상위 디렉토리에는 README, Config 등의 항목이 포함될 수 있다.

어려운 선택은 a를 사용할 것인가 말 것인가 이다./src나무. 파이톤은 서로 구별하지 않는다./src,/lib그리고/bin자바나 C가 가지고 있는 것처럼.

최상위 단계 이후/src일부 사람들은 디렉토리가 무의미하다고 생각하지만, 최상위 디렉토리는 애플리케이션의 최상위 아키텍처가 될 수 있다.

• /foo
• /bar
• /baz

나는 이 모든 것을 "내 제품 이름" 디렉토리에 넣을 것을 추천한다.그래서, 만약 당신이 이름붙인 어플리케이션을 쓴다면quux, 이 모든 것을 포함하는 디렉토리 이름이 지정됨/quux.

다른 프로젝트의 경우PYTHONPATH, 그러면 다음을 포함할 수 있다./path/to/quux/foo를 재사용하다QUUX.foo모듈

나의 경우 코모도 편집을 사용하기 때문에 IDE cuft는 싱글이다.KPF 파일.난 사실 그걸 최고 레벨에 올려놨어./quux디렉터리, SVN에 추가하지 마십시오.

Python 프로젝트의 Jean-Paul Calderone의 Filesystem 구조에 따르면:

Project/
|-- bin/
|   |-- project
|
|-- project/
|   |-- test/
|   |   |-- __init__.py
|   |   |-- test_main.py
|   |   
|   |-- __init__.py
|   |-- main.py
|
|-- setup.py
|-- README

This blog post by Jean-Paul Calderone is commonly given as an answer in #python on Freenode.

Filesystem structure of a Python project

Do:

• name the directory something related to your project. For example, if your project is named "Twisted", name the top-level directory for its source files Twisted. When you do releases, you should include a version number suffix: Twisted-2.5.
• create a directory Twisted/bin and put your executables there, if you have any. Don't give them a .py extension, even if they are Python source files. Don't put any code in them except an import of and call to a main function defined somewhere else in your projects. (Slight wrinkle: since on Windows, the interpreter is selected by the file extension, your Windows users actually do want the .py extension. So, when you package for Windows, you may want to add it. Unfortunately there's no easy distutils trick that I know of to automate this process. Considering that on POSIX the .py extension is a only a wart, whereas on Windows the lack is an actual bug, if your userbase includes Windows users, you may want to opt to just have the .py extension everywhere.)
• If your project is expressable as a single Python source file, then put it into the directory and name it something related to your project. For example, Twisted/twisted.py. If you need multiple source files, create a package instead (Twisted/twisted/, with an empty Twisted/twisted/__init__.py) and place your source files in it. For example, Twisted/twisted/internet.py.
• put your unit tests in a sub-package of your package (note - this means that the single Python source file option above was a trick - you always need at least one other file for your unit tests). For example, Twisted/twisted/test/. Of course, make it a package with Twisted/twisted/test/__init__.py. Place tests in files like Twisted/twisted/test/test_internet.py.
• add Twisted/README and Twisted/setup.py to explain and install your software, respectively, if you're feeling nice.

Don't:

• put your source in a directory called src or lib. This makes it hard to run without installing.
• put your tests outside of your Python package. This makes it hard to run the tests against an installed version.
• create a package that only has a __init__.py and then put all your code into __init__.py. 패키지 대신 모듈만 만들어주면 간단해.
• 파이썬이 당신의 모듈이나 패키지를 가져올 수 있도록 마법의 해킹을 고안해내려고 하는데, 그것은 사용자가 그것을 포함하는 디렉토리를 그들의 가져오기 경로에 추가하지 않아도 된다(PYONPATH 또는 다른 메커니즘을 통해서).당신은 모든 사건을 올바르게 처리하지 못할 것이고 사용자들은 당신의 소프트웨어가 그들의 환경에서 작동하지 않을 때 당신에게 화를 낼 것이다.

Python Project the Right Way에서 Open Sourcing a Python Project를 확인하십시오.

그 훌륭한 기사의 프로젝트 레이아웃 부분을 발췌해 봅시다.

프로젝트를 설정할 때 레이아웃(또는 디렉토리 구조)을 올바르게 하려면 중요하다.합리적인 레이아웃은 잠재적 기여자들이 코드 조각을 찾기 위해 영원히 시간을 보낼 필요가 없다는 것을 의미한다. 파일 위치는 직관적이다.우리가 기존 프로젝트를 다루고 있기 때문에, 그것은 당신이 아마도 몇 가지 물건을 옮겨야 한다는 것을 의미해.

맨 위에서 시작합시다.대부분의 프로젝트에는 다수의 최상위 파일(예: setup.py, README.md, README.md, 요구 사항들이 있다.txt 등).그러면 모든 프로젝트에는 다음과 같은 세 개의 디렉터리가 있어야 한다.

• 프로젝트 문서를 포함하는 문서 디렉토리
• 실제 Python 패키지를 저장하는 프로젝트 이름으로 명명된 디렉토리
• 두 위치 중 하나에 있는 테스트 디렉터리
  • 테스트 코드 및 리소스가 들어 있는 패키지 디렉터리 아래
  • 독립 실행형 최상위 디렉토리로서 파일 구성 방법을 보다 잘 이해하기 위해 내 프로젝트 중 하나인 Sandman:

$ pwd
~/code/sandman
$ tree
.
|- LICENSE
|- README.md
|- TODO.md
|- docs
|   |-- conf.py
|   |-- generated
|   |-- index.rst
|   |-- installation.rst
|   |-- modules.rst
|   |-- quickstart.rst
|   |-- sandman.rst
|- requirements.txt
|- sandman
|   |-- __init__.py
|   |-- exception.py
|   |-- model.py
|   |-- sandman.py
|   |-- test
|       |-- models.py
|       |-- test_sandman.py
|- setup.py

보시다시피 최고 수준의 파일, 문서 디렉토리(생성된 것은 스핑크스가 생성된 문서를 넣을 빈 디렉토리), 샌드맨 디렉토리, 테스트 디렉토리 등이 있다.

"피톤 포장 당국"은 다음과 같은 샘플 프로젝트를 가지고 있다.

https://github.com/pypa/sampleproject

Python Packaging User Guide의 Packaging and Distribution Projects에 대한 자습서에 대한 보조 자료로 존재하는 샘플 프로젝트 입니다.

python_boilerplate 템플릿을 사용하여 프로젝트를 시작해 보십시오.이 방법은 대부분 모범 사례(예: 여기 있는 방법)를 따르지만, 어느 시점에서 프로젝트를 둘 이상의 난자로 분할할 의사가 있는 경우(그리고 내 말을 믿어, 가장 간단한 프로젝트를 제외하고는)에 더 적합할 것이다.한 가지 일반적인 상황은 로컬로 수정된 다른 사람의 라이브러리 버전을 사용해야 하는 경우다.

• 출처를 어디에 두느냐?

  • 확실히 규모가 큰 프로젝트의 경우 소스를 여러 개의 달걀로 나누는 것이 타당하다.각각의 알은 아래 별도의 세투프풀로 쓰일 것이다.PROJECT_ROOT/src/<egg_name>.

• 응용 프로그램 시작 스크립트를 어디에 두십니까?

  • 이상적인 옵션은 애플리케이션 시작 스크립트를entry_point달걀 한 개에

• IDE 프로젝트는 어디에 두십니까?

  • IDE에 따라 다름.그들 중 많은 사람들은 그들의 물건을 보관한다.PROJECT_ROOT/.<something>프로젝트의 근본에, 그리고 이건 괜찮아.

• 단위/수락 테스트는 어디에 두십니까?

  • 각각의 달걀은 따로 시험 세트를 가지고 있으며, 그 안에 보관되어 있다.PROJECT_ROOT/src/<egg_name>/tests전화번호부나는 개인적으로 사용하는 것을 선호한다.py.test운영하기 위해서.

• 구성 파일과 같은 비 Python 데이터는 어디에 저장하십니까?

  • 사정에 따라 다르겠지.다른 종류의 비피톤 데이터가 있을 수 있다.
    • "리소스" 즉, 달걀 안에 포장해야 하는 데이터.이 데이터는 패키지 네임스페이스 내의 해당 에그 디렉토리로 이동한다.를 통해 사용할 수 있다.pkg_resources에서 포장하다.setuptools또는 Python 3.7 이후부터importlib.resources표준 라이브러리의 모듈.
    • "Config-files(구성 파일)", 즉 프로젝트 소스 파일의 외부로 간주해야 하지만 애플리케이션이 실행되기 시작할 때 일부 값으로 초기화해야 하는 비 Python 파일.개발 중에는 이러한 파일을 보관하는 것이 좋다.PROJECT_ROOT/config배포에는 다양한 옵션이 있을 수 있다.Windows(윈도우)에서%APP_DATA%/<app-name>/config, Linux에서,/etc/<app-name>또는/opt/<app-name>/config.
    • 생성된 파일, 즉 실행 중에 응용 프로그램에 의해 생성되거나 수정될 수 있는 파일.나는 그들을 안에 가두어 두고 싶다.PROJECT_ROOT/var개발 중에 그리고 개발 중에/var리눅스 배포 중.
• pyd/so 바이너리 확장 모듈용 C++와 같은 비 Python 소스를 어디에 두십니까?
  • 안으로PROJECT_ROOT/src/<egg_name>/native

일반적으로 문서화는PROJECT_ROOT/doc또는PROJECT_ROOT/src/<egg_name>/doc(이것은 일부 달걀을 별도의 대형 프로젝트로 간주하는지에 따라 달라진다.)일부 추가 구성은 다음과 같은 파일에 있을 것이다.PROJECT_ROOT/buildout.cfg그리고PROJECT_ROOT/setup.cfg.

내 경험상 그것은 반복의 문제일 뿐이다.데이터와 코드를 원하는 곳에 저장하십시오.어차피 틀릴 거야하지만 정확히 어떻게 일이 형성될지에 대한 더 나은 생각을 갖게 되면, 여러분은 이런 종류의 추측을 할 수 있는 훨씬 더 좋은 위치에 서게 된다.

확장 소스에 한해서, 우리는 코드에 파이톤용 디렉토리와 다양한 다른 언어들을 위한 디렉토리를 포함하는 코드 디렉토리를 가지고 있다.개인적으로, 나는 다음번에는 어떤 확장 코드든 그 자체의 저장소에 넣어보고 싶어.

그 말을 들으니, 나는 내 첫 번째 요점으로 되돌아간다: 그것으로 너무 큰 거래를 하지 말라는 것이다.너에게 효과가 있을 것 같은 곳에 갖다 놓아라.만약 당신이 효과가 없는 것을 발견한다면, 그것은 바뀔 수 있고, 또한 바뀌어야 한다.

Python이 아닌 데이터는 다음을 사용하여 Python 모듈 내에 가장 잘 번들로 제공됨package_data셋톱풀을 지지하다네임스페이스 패키지를 사용하여 여러 프로젝트에서 사용할 수 있는 공유 네임스페이스(Namepace)를 만드는 것이 좋습니다, 마치 패키지를 넣는 Java 협약과 유사함com.yourcompany.yourproject(그리고 공유될 수 있는 것com.yourcompany.utils네임스페이스).

분기 및 병합 시 충분한 소스 제어 시스템을 사용하면 이름을 바꾸더라도 병합 작업을 처리할 수 있다. Baza는 특히 이 기능을 잘한다.

여기 있는 다른 대답들과는 달리, 나는 더 많은 것을 가지고 있다.src디렉터리 최상위 수준(사용 포함)doc그리고test옆에 있는 디렉토리.예를 들어, 스핑크스는 빠른 시작 도구가 지원하는 자체 규칙을 가지고 있다.

setuptools 및 pkg_resource를 활용하십시오. 이렇게 하면 다른 프로젝트가 사용자 코드의 특정 버전에 훨씬 쉽게 의존할 수 있으며, 사용 중인 경우 여러 버전이 서로 다른 비 코드 파일과 동시에 설치될 수 있음package_data).

참조URL: https://stackoverflow.com/questions/193161/what-is-the-best-project-structure-for-a-python-application