复杂的 Python 目录规范

[Grandmasters]

想知道 Python 有没有具体的比较复杂的目录规范
Google 上大致翻了一下，基本都是比较简单的那种。
平时用的大概文件夹名大概有:
一级：bin,data,src
二级：api,db,lib,utils
三级：具体的模块

另外想问如果和前端(TypeScript)合作是否合适放在一个仓库内，怎么放比较合适。

高中生勿喷，感谢。

[ericls]

放有什么优缺点？ 不放有什么优缺点？
你的目的事什么 哪一种做法能更好满足你的目的？

我的前后端在一个 repo, 因为我的前后端不分人，部署也是一起部署的 也只用保证同一个 commit 的 前后端相互兼容。 如果分 repo overhead 将大大加大，而得不到别的好处。

不要管什么范例, pattern 什么的 这些都是答案
先看问题 再看答案

问题都没看清楚 抄答案也会抄错的

[Pagliacii]

Python 没有具体地说项目结构该怎么组织。你可以参考这个库 https://github.com/cookiecutter/cookiecutter
，找找模版，看看其他人是怎么组织项目结构的。

[Austin2035]

你看一下 requests 源码（典型的 pythonic ），没有多级目录，真正的源码就一级，何必搞那么多级？

[hushao]

Python 你就随心所欲的想怎么写就怎么写，随着项目复杂度提高，逐渐的抽象、剥离，既然采用 Python 了，固化的结果就是开局就提高了复杂度，降低了编码效率，反而不值得。

[hushao]

和前端可以放在一个大目录下，采用 submodule 方式

[GeruzoniAnsasu]

啥 高中生

哦那没有，django 怎么摆目录的照着往里填就得了



“复杂目录结构” 是上万个工作日才能累积出来的，你现阶段大概完全接触不到

p.s. 上万工作日的算法是 30 人核心小组 20 人外围 /组件开发从零到成熟化约一年左右的量

[Trim21]

如果是个 package 的话全都放在 package_name/ 里面，bin 用 entry_point

[freakxx]

可以借鉴 django 的做法，比较符合 python reusable 的一种设计思路；

到最后你的结构可能会变成
- config
- apps
- resource
- utils

这几个大结构，在这上面再延伸出去；

[freakxx]

> 另外想问如果和前端(TypeScript)合作是否合适放在一个仓库内，怎么放比较合适。


放在一起可以的，分支可以这么考虑，适当调整；
main - dev -test - frontend + backend - dev_<user>

代码的话，各自放在项目层
- frontend/
- backend/
- ReadME.md 等

[no1xsyzy]

poetry new 就行了，管那么多干嘛（
复杂了再切割就是了

和前端合作，两个人的话不建议放一个 branch，但可以放同一个仓库，建两个 orphan branch 然后 master 里塞两个 submodule，顺便还把版本 pin 住了（这样的话 commit history 会放三份？有点傻逼）

[RockShake]

前后端一起放在一个大目录下，我曾经碰到过一个跟 IDE 相关的问题。Frontend 文件夹内直接用 CLI 等工具自动生成项目模板，在 VS Code 中 ESlint 报错，无法编译通过，找不到对应的包。后来发现必须在根目录下用 CLI 工具生成前端项目，或者必须用 VS Code 单独打开 Frontend 文件夹才能避免该问题。

[Rheinmetal]

构建的有标准
pep 517 还是 518 来着
没搞过大项目是理解不了的