不太重要。只要能让你开心就行。没有很多愚蠢的规则，因为Python项目可以很简单。

/scripts或/bin之类的命令行界面 /测试你的测试 /lib为您的c语言库 /doc用于大多数文档 /apidoc用于epydoc生成的API文档。

顶层目录可以包含README, Config等等。

困难的选择是是否使用/src树。Python不像Java或C那样区分/src、/lib和/bin。

由于一些人认为顶级/src目录没有意义，所以顶级目录可以是应用程序的顶级体系结构。

/ foo /酒吧 /巴兹

我建议把所有这些都放在“我的产品名称”目录下。如果你写一个名为quux的应用程序，包含这些东西的目录就叫做/quux。

然后，另一个项目的PYTHONPATH可以包含/path/to/quux/foo来重用quux。foo模块。

在我的例子中，因为我使用Komodo Edit，所以我的IDE cuft是一个. kpf文件。实际上，我将其放在顶级/quux目录中，并忽略将其添加到SVN。

根据Jean-Paul Calderone的Python项目文件系统结构:

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

以正确的方式查看Python项目的开源。

让我摘录这篇优秀文章的项目布局部分:

When setting up a project, the layout (or directory structure) is important to get right. A sensible layout means that potential contributors don't have to spend forever hunting for a piece of code; file locations are intuitive. Since we're dealing with an existing project, it means you'll probably need to move some stuff around. Let's start at the top. Most projects have a number of top-level files (like setup.py, README.md, requirements.txt, etc). There are then three directories that every project should have: A docs directory containing project documentation A directory named with the project's name which stores the actual Python package A test directory in one of two places Under the package directory containing test code and resources As a stand-alone top level directory To get a better sense of how your files should be organized, here's a simplified snapshot of the layout for one of my projects, 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 As you can see, there are some top level files, a docs directory (generated is an empty directory where sphinx will put the generated documentation), a sandman directory, and a test directory under sandman.

“Python打包权威”有一个样本项目:

https://github.com/pypa/sampleproject

它是一个示例项目，作为Python打包用户指南的打包和分发项目教程的辅助而存在。

这篇由Jean-Paul Calderone撰写的博客文章通常是Freenode上#python的答案。

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. Just make a module instead of a package, it's simpler. try to come up with magical hacks to make Python able to import your module or package without having the user add the directory containing it to their import path (either via PYTHONPATH or some other mechanism). You will not correctly handle all cases and users will get angry at you when your software doesn't work in their environment.

尝试使用python_boilerplate模板启动项目。它在很大程度上遵循了最佳实践(例如这里的那些)，但如果你发现自己愿意在某个时候把项目分成多个鸡蛋(相信我，除了最简单的项目，你会这样做)，它更适合你。一种常见的情况是，您必须使用别人库的本地修改版本)。

Where do you put the source? For decently large projects it makes sense to split the source into several eggs. Each egg would go as a separate setuptools-layout under PROJECT_ROOT/src/<egg_name>. Where do you put application startup scripts? The ideal option is to have application startup script registered as an entry_point in one of the eggs. Where do you put the IDE project cruft? Depends on the IDE. Many of them keep their stuff in PROJECT_ROOT/.<something> in the root of the project, and this is fine. Where do you put the unit/acceptance tests? Each egg has a separate set of tests, kept in its PROJECT_ROOT/src/<egg_name>/tests directory. I personally prefer to use py.test to run them. Where do you put non-Python data such as config files? It depends. There can be different types of non-Python data. "Resources", i.e. data that must be packaged within an egg. This data goes into the corresponding egg directory, somewhere within package namespace. It can be used via the pkg_resources package from setuptools, or since Python 3.7 via the importlib.resources module from the standard library. "Config-files", i.e. non-Python files that are to be regarded as external to the project source files, but have to be initialized with some values when application starts running. During development I prefer to keep such files in PROJECT_ROOT/config. For deployment there can be various options. On Windows one can use %APP_DATA%/<app-name>/config, on Linux, /etc/<app-name> or /opt/<app-name>/config. Generated files, i.e. files that may be created or modified by the application during execution. I would prefer to keep them in PROJECT_ROOT/var during development, and under /var during Linux deployment. Where do you put non-Python sources such as C++ for pyd/so binary extension modules? Into PROJECT_ROOT/src/<egg_name>/native

文档通常会进入PROJECT_ROOT/doc或PROJECT_ROOT/src/<egg_name>/doc(这取决于您是否将某些eggs视为单独的大型项目)。一些额外的配置将在PROJECT_ROOT/build - out.cfg和PROJECT_ROOT/setup.cfg这样的文件中。