导出依赖到 requirements.txtpip install pipreqs pipreqs . --encodingutf8 --force但是直接使用pip安装不了torch需要添加源pip install -r requirements.txt -f https://download.pytorch.org/whl/torch_stable.html想到一个麻烦的解决方法先conda env export environments.yml导出环境然后把conda部分和pip部分分开pip部分放进去 requirements.txt 里面然后再手动安装# please run these commands manually in your terminal conda env create -f environment.yml conda activate Multi-OSCCPI pip install torch1.13.0cu116 torchvision0.14.0cu116 -f https://download.pytorch.org/whl/torch_stable.html pip install -r requirements.txtpython 项目中 setup.py 文件的作用是什么参考https://zhuanlan.zhihu.com/p/276461821包分发的始祖distutilsdistutils 是 Python 的一个标准库从命名上很容易看出它是一个分发distribute工具utlis它是 Python 官方开发的一个分发打包工具所有后续的打包工具全部都是基于它进行开发的。distutils 的精髓在于编写 setup.py它是模块分发与安装的指导文件。如果一个项目使用python setup.py install来安装依赖那么这个项目的安装方法是通过源码安装。相反与之对应的是通过二进制软件包的安装。这里整个项目都是一个包分发工具升级setuptoolssetuptools 是 distutils 增强版不包括在标准库中。其扩展了很多功能能够帮助开发者更好的创建和分发 Python 包。大部分 Python 用户都会使用更先进的 setuptools 模块。distribute或许你在其他地方也见过它这里也提一下。distribute 是 setuptools 有一个分支版本分支的原因可能是有一部分开发者认为 setuptools 开发太慢了。但现在distribute 又合并回了 setuptools 中。因此我们可以认为它们是同一个东西。因此setuptools 是一个优秀的可靠的 Python 包安装与分发工具。源码包与二进制包什么区别Python 包的分发可以分为两种1、以源码包的方式发布源码包安装的过程是先解压再编译最后才安装所以它是跨平台的由于每次安装都要进行编译相对二进包安装方式来说安装速度较慢。2、以二进制包形式发布二进制包的安装过程省去了编译的过程直接进行解压安装所以安装速度较源码包来说更快。由于不同平台的编译出来的包无法通用所以在发布时需事先编译好多个平台的包。二进制包的常见格式有eggs 与 wheels 有什么区别Egg 格式是由 setuptools 在 2004 年引入而 Wheel 格式是由 PEP427 在 2012 年定义。Wheel 的出现是为了替代 Egg它的本质是一个zip包其现在被认为是 Python 的二进制包的标准格式。以下是 Wheel 和 Egg 的主要区别Wheel 有一个官方的 PEP427 来定义而 Egg 没有 PEP 定义Wheel 是一种分发格式即打包格式。而 Egg 既是一种分发格式也是一种运行时安装的格式并且是可以被直接 importWheel 文件不会包含 .pyc 文件Wheel 使用和 PEP376 兼容的 .dist-info 目录而 Egg 使用 .egg-info 目录Wheel 有着更丰富的命名规则。Wheel 是有版本的。每个 Wheel 文件都包含 wheel 规范的版本和打包的实现Wheel 在内部被 sysconfig path type 管理因此转向其他格式也更容易wheel 包可以通过 pip 来安装只不过需要先安装 wheel 模块然后再使用 pip 的命令。如何编写setup.py文件暂时不那么重要。。。参与项目开发之后如何管理分支 完整操作流程从克隆后开始假设你已经克隆了仓库git clone xxx cd ai-backend1️⃣ 确保本地 deploy/test 是最新代码git checkout deploy/test # 切换到测试分支 git pull origin deploy/test # 拉取远程最新代码2️⃣ 基于最新的 deploy/test 创建你的功能分支分支命名规则feat/你的名字/功能例如你的名字是 zhang功能是 add-logingit checkout -b feat/zhang/add-login创建分支git branch feat/zhang/add-login删除分支git branch -d feat/zhang/add-login现在你已经在自己分支上了。3️⃣ 进行开发、提交开发你的模块完成后git add . # 添加所有修改或指定文件 git commit -m feat: 增加登录模块 # 提交信息要清晰可以多次提交每次都要写清楚做了什么。4️⃣ 可选开发期间同步 deploy/test 的更新如果你的功能开发时间较长期间同事可能往 deploy/test 推送了新代码为了避免最后合并时冲突太多可以随时把他们的更新拉到自己分支git pull origin deploy/test # 把 deploy/test 的新代码合并到当前分支 # 如果有冲突解决后 git add . 再 git commit5️⃣ 功能开发完成合并到 deploy/testgit checkout deploy/test # 切回 deploy/test git pull origin deploy/test # 再次拉取最新确保合并前是最新的 git merge feat/zhang/add-login # 把你的功能分支合并进来如果提示冲突解决冲突编辑冲突文件 → git add . → git commit。6️⃣ 推送 deploy/test 到远程仓库git push origin deploy/test推送成功后Coolify 会自动检测到 deploy/test 分支更新并开始部署到测试环境。7️⃣ 可选推送你的功能分支到远程备份虽然 leader 没说必须推但建议也把你的功能分支推送到远程方便其他人查看或备份git push origin feat/zhang/add-login注意 如果担心搞坏了 deploy/test那么就最好采用提PR的方式合并。1方式一直接合并推送操作本地完成开发 → 合并到 deploy/test → git push origin deploy/test耗时几乎为零推送后立即触发部署。适用场景小型团队、快速迭代、开发分支deploy/test允许直接推送。2方式二提 PR 再合并操作将功能分支推送到远程 → 在 GitHub 上创建 PR → 等待 review → 由 reviewer 合并或自己合并耗时取决于 review 速度可能几分钟到几天。适用场景需要代码审查、多人协作、保护主分支如 main。不对应该基于prod进行开发那我上面基于 deploy/test 开发的内容进行了备份之后我要重新把 /dev/xxx/memory 改到指向 deploy/prod 。一步到位的修复git checkout deploy/prod # 先回到 deploy/prod git branch --set-upstream-toorigin/deploy/prod deploy/prod git fetch origin # 拉远端信息 git reset --hard origin/deploy/prod # 强制对齐远端 ★ 这里会丢掉 deploy/prod 上的未保存内容/本地提交 # 现在 deploy/prod origin/deploy/prod这个时候 deploy/prod 已经跟上游对齐了git checkout dev/pigeong/memory git reset --hard deploy/prod # 把dev分支对齐回prod ★ 这里会丢掉 dev/pigeong/memory 上的未保存内容/本地提交