6

按照 关于 Django 可重用应用程序的教程，一切正常。但是我对开发和打包 Django 应用程序的过程有一些疑问。

1 - 在本教程中，首先在项目中开发应用程序。然后，将其复制粘贴到另一个文件夹中进行打包，然后通过 pip 再次包含在项目中。这是开发 Django 应用程序的方式吗？例如，如果我必须包含新功能或修复错误，我是否应该在项目中进行更改，然后将它们复制粘贴到项目外部的包文件夹中？

2 - 假设 1 不是开发应用程序的唯一方法，我开始使用以下结构为我的应用程序创建一个包文件夹：

django-myApp
|--myApp
|  |--models
|     |--file1.py
|     |--file2.py
|--setup.py
|--README.rst

运行python3 setup.py sdist并安装它后，pip3 install --user myApp.tar.gz我可以从新的 Django 项目 shell 成功导入我的应用程序。但是当我运行 python3 manage.py migrate 时，没有创建 myApp 模型的表。我想这是因为 myApp 包中没有迁移文件夹，据我所知，创建迁移的唯一方法是makemigrations在项目中运行。还是我错过了一些基本的东西？我可以在项目中没有应用程序的情况下生成初始迁移模块吗？

3 - 最后，主要问题是：在开发应用程序时，我是否必须启动一个项目，复制应用程序文件夹进行打包，通过安装重新包含它，然后在包文件夹中继续开发？

提前感谢您的任何评论或指导。

PD：对不起我的英语，关于它的评论也很受欢迎

编辑1：

一个突出我怀疑的例子：完成教程后，应用程序源代码在项目之外，假设我需要更改模型。我可以在 App 文件夹中更改它们，发布一个新版本（例如 0.2）并安装它。现在，如何为这些更改生成迁移？我应该总是有一个测试项目吗？

4

3 回答 3

14

此外，开发过程中一个好的工作流程是将可重用的应用程序链接到您的 Django 项目中。为了轻松实现这pip install一点，-e, --editable可以选择从setuptools 开发模式派生。

可重复使用的应用程序：

django-myApp
|--myApp
|  |--models
|     |--file1.py
|     |--file2.py
|--setup.py
|--README.rst

Django 设置：

my-django-project
|--my_django_project
|  |--settings.py
|  |--urls.py
|  |--wsgi.py
|  |--...
|--manage.py

激活 virtualenv 后，您现在可以通过运行将可重用应用程序链接到项目：

(myvenv) $ pip install --editable /path/to/django-myApp

现在，您所做的每一项更改都会django-myApp自动反映出来，my-django-project而无需先构建/打包可重用应用程序。

这在许多用例中变得很方便。Python 2.x例如，想象开发应用程序以与和兼容Python 3.x。通过链接，您可以将应用程序安装到两个（或更多）不同的 Django 设置中并运行您的测试。

于 2015-06-10T07:55:32.417 回答
4

  1. 当您打包一个应用程序时，是因为您认为值得在多个项目中使用它并且它本身具有一些价值。一旦处于良好状态（最小功能正常工作），您可以按照指南保持您的应用程序可重用和打包。好的，你的应用已经准备好了，它可以做你想做的，所以现在你想把它从你的项目中分离出来吗？按照您链接的教程获取有关文件夹结构的指南并将其上传到存储库。也添加一些测试，它们是必须的。您现在可以使用几种方法将其重新添加到您的项目中。

    • 打包它并通过 pip 从 tar.gz 安装它（或直接从存储库）
    • 将您的存储库克隆为子模块
    • 在项目中保留副本并在存储库中手动更新更改

我不是第三个的粉丝。第二种选择有其注意事项，但它可以工作。我绝对更喜欢第一个。

围绕您的新应用创建一个测试项目，并使用它来开发它的新功能（只需最低测试要求），更新您的存储库，最后通过 pip 更新您项目中的应用。您的应用程序现在不依赖于您的项目，因此不要将您的应用程序绑定到它。

  1. 您是否将其添加到您的 INSTALLED_APPS 中？如果你这样做了，请检查你的 models.py 是否可以访问......尝试使用 django shell。尝试创建迁移模块以查看它是否有效，无论如何这不会花费很长时间。

  2. 最后的答案是：不，您的应用程序现在是一个不同的项目，您继续在存储库上开发，就像您对任何其他项目所做的那样，然后像您对发布新版本的任何其他应用程序所做的那样进行更新。您根本不需要（也不应该）触摸您的 virtualenv 的文件夹。

这些是在您的应用中更新的步骤：

  • 您发现了一个令人讨厌的错误或想到了一些不错的功能
  • 你添加了测试来覆盖它
  • 您更新了代码以增强您的应用
  • 您重复最后几个步骤，直到您的应用再次稳定
  • 如果你的应用程序在 Pypi 中，你发布一个新包并从那里更新它，否则你从存储库更新它。

这显然比在您的项目中开发应用程序需要更长的时间，但这样做有助于确保良好的质量，并且不会给您的项目带来问题。

于 2015-06-10T01:24:03.913 回答
1

我在开发这个库（ django-nsync ）时遇到了类似的情况。

我通过创建一个脚本来“解决”这个问题，该makemigrations.py脚本设置一个最小的 Django 设置以包含“应用程序”，然后调用该makemigrations命令。

脚本如下所示：

def make_migrations():
    from django.core.management import call_command
    call_command('makemigrations', '<YOUR APP NAME>')


if __name__ == '__main__':
    import sys
    # I need to add the 'src' folder to PYTHON PATH
    sys.path.append('./src/')

    try:
        from django.conf import settings

        settings.configure(
            INSTALLED_APPS=[
                '<ANY APPS YOUR APP DEPENDS ON>',
                '<YOUR APP NAME>',
            ],
        )

        import django
        django.setup()

    except ImportError:
        import traceback
        traceback.print_exc()
        raise ImportError('To fix this error, sort out the imports')

    make_migrations()

该脚本不需要单独的项目来创建迁移。

注意：我试图将它连接到 setup.py 东西中，以便每当您尝试构建（或更重要的是发布）库时，它会检查迁移是否是最新的/在源代码管理中。但是，我放弃了，因为：

  1. 我希望不必为 NSync 库做太多事情。
  2. 它很快就变得一团糟（比如检查迁移文件夹中有多少文件，然后运行迁移，然后再次检查，然后删除文件？还是留下它们？我应该在发布时强制执行吗？我应该像 bumpversion 那样检查 Git 吗？等等……）
于 2015-12-07T14:44:03.650 回答