virtualenv 中的版本控制南迁移
我在 site/ 文件夹中放置了一个 Django 站点。它处于版本控制之下。我使用 South 为我的应用程序进行架构和数据迁移。特定于站点的应用程序位于文件夹 site/ 下，因此它们及其迁移都受到版本控制。
我管理一个 virtualenv 来保持第三方组件干燥和安全。我通过 PyPI 安装软件包。已安装的软件包列表被冻结在requirements.txt中，以便它们可以轻松地安装在另一个环境中。 virtualenv 不在 VCS 下。我认为如果 virtualenv 可以随时轻松删除和重建，这是一个好方法。例如，如果我需要测试我的网站，使用另一个版本的 Python 解释器，只需激活另一个 virtulalenv 即可。
不过，我想将 South 用于第三方软件包。问题来了。迁移脚本存储在应用程序的文件夹中，因此它们位于我的站点存储库之外。但我希望迁移脚本处于版本控制之下，这样我也可以在不同的阶段运行它们。
我不想对整个 virtualenv 进行版本控制，而是对第三方应用程序的迁移脚本进行版本控制。我该如何解决这个冲突？我的场景是否存在任何误解？
I have a Django site placed in folder site/. It's under version control. I use South for schema and data migrations for my applications. Site-specific applications are under folder site/ so they are all version-controlled along with their migrations.
I manage a virtualenv to keep third party components dry and safe. I install packages via PyPI. The installed packages' list are frozen in requirements.txt so the they can be easily installed in another environment. The virtualenv is not under VCS. I think it is a good way if virtualenv can be easly deleted and reconstructed at any time. If I need to test my site, for instance, using another version of Python interpreter, simply activate another virtulalenv.
I'd like to use South for third party packages, though. Here comes the problem. Migration scripts stored in the application's folder so they are outside of my site's repository. But I want migration scripts to be under version control so I can run them on different stages as well.
I don't want to version control the whole virtualenv but the migration scripts for third party applications. How can I resolve this conflict? Is there any misconcept in my scenario?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
SOUTH_MIGRATION_MODULES 设置 允许您将指定应用程序的迁移模块放置在您想要的任何位置（即内部）您的项目树）。
The SOUTH_MIGRATION_MODULES setting allows you to put migration modules for specified apps wherever you want them (i.e. inside your project tree).
我认为这在一定程度上取决于您的版本控制系统。我建议使用稀疏树，它只管理各种包的迁移文件夹。在这里，我看到了两种替代方案：
为所有包创建一棵真正稀疏的树，您在创建 virtualenv 之前检查该树。然后填充 virtualenv，将内容放入现有文件夹中。
将所有迁移收集到单独的存储库中，每个项目/外部依赖项都有一个文件夹。将其签入 virtualenv，并创建符号链接，从每个项目链接到其迁移文件夹。
无论哪种情况，我相信您都可以安排迁移作为单独的项目存在，这样您就可以使用与安装其他所有内容相同的过程来安装它（easy_install/pip/whatever）。
I think it depends a litte bit on your version control system. I recommend to use a sparse tree, one that only manages the migration folders of the various packages. Here I see two alternatives:
Make a truly sparse tree for all packages, one that you check out before creating the virtualenv. Then populate the virtualenv, putting stuff into the existing folders.
Collect all migrations into a separate repository, with a folder per project/external dependency. Check this out into the virtualenv, and create symlinks, linking from each project to its migration folder.
In either case, I believe you can arrange for the migrations to exist as a separate project, so you can install it with the same process as you install everything else (easy_install/pip/whatever).