Python 为什么“flask_引导”无法导入？

运行flask应用程序时，Apache2的

错误。日志

显示无法找到

flask_引导

模块：

[wsgi:warn] mod_wsgi: Compiled for Python/2.7.11.
[wsgi:warn] mod_wsgi: Runtime using Python/2.7.12.
[mpm_event:notice] AH00489: Apache/2.4.18 (Ubuntu) mod_wsgi/4.3.0 Python/2.7.12 configured -- resuming normal operations
[core:notice] AH00094: Command line: '/usr/sbin/apache2'
[wsgi:error] mod_wsgi (pid=18587): Target WSGI script '/var/www/myapp/myapp.wsgi' cannot be loaded as Python module.
[wsgi:error] mod_wsgi (pid=18587): Exception occurred processing WSGI script '/var/www/myapp/myapp.wsgi'.
[wsgi:error] Traceback (most recent call last):
[wsgi:error]   File "/var/www/myapp/myapp.wsgi", line 7, in <module>
[wsgi:error]     from myapp import app as application 
[wsgi:error]   File "/var/www/myapp/myapp/__init__.py", line 2, in <module>
[wsgi:error]     from flask_bootstrap import Bootstrap
[wsgi:error] ImportError: No module named flask_bootstrap

该模块可在系统范围内和venv中使用：

root@host:/var/www/myapp# python
Python 2.7.12 (default, Dec  4 2017, 14:50:18) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from flask_bootstrap import Bootstrap
>>> Bootstrap
<class 'flask_bootstrap.Bootstrap'>

---

没有任何区别。

事实证明，问题在于这两行：

WSGIProcessGroup myapp
WSGIApplicationGroup %{GLOBAL}

应该在

内

因此，

myapp.conf

现在看起来像这样：

<VirtualHost *:80>
        ServerName yourdomain.com

        WSGIDaemonProcess myapp python-home=/var/www/myapp/myapp/venv
        WSGIScriptAlias / /var/www/myapp/myapp.wsgi

        <Directory /var/www/myapp/myapp>
                WSGIProcessGroup myapp
                WSGIApplicationGroup %{GLOBAL}
                Order deny,allow
                Allow from all
        </Directory>

        ErrorLog ${APACHE_LOG_DIR}/error.log
        LogLevel warn
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

ServerName yourdomain.com
WSGIDaemonProcess myapp python home=/var/www/myapp/myapp/venv
WSGIScriptAlias//var/www/myapp/myapp.wsgi
WSGIProcessGroup myapp
WSGIApplicationGroup%{GLOBAL}
命令拒绝，允许
通融
ErrorLog${APACHE_LOG_DIR}/error.LOG
日志级别警告
CustomLog${APACHE\u LOG\u DIR}/access.LOG组合

公平地说，这与中的示例相同

---

非常感谢所有发表评论的人：）

因此，在格雷厄姆说服我我的“修复”（将两行移到

指令中）并不是真正的修复，可能是其他问题的迹象之后，我决定深入挖掘

具体来说，在这些文档之后，我惊讶地发现，当在我的本地设备上激活虚拟环境时（不是通过wsgi应用程序）：

当我期望它是：

sys.prefix = '/var/www/myapp/myapp/venv'

我不知道这是怎么发生的。可能是作为

root

执行所有初始工作的结果

---

不过，很高兴地说，删除并重新创建虚拟环境，这一次作为普通用户，一切似乎都很好。

补丁级别的版本差异并不重要。由于您是以

root

身份测试导入，所以我关心的是，安装的包是否具有正确的权限，并且是否可以由Apache运行的用户找到。另外，对于激活的虚拟环境，从Python解释器

sys.prefix

可以得到什么？这应该与您提供给

python home

选项的内容相匹配。是的，

sys.prefix

确实匹配

python home

：：使用

activate\u这不是推荐的方法。如何将虚拟环境与mod_wsgi一起使用在中进行了描述，我还建议将
LogLevel
设置为
info
，以便mod_wsgi记录更多关于它正在做什么的信息。它在第一次加载WSGI脚本时输出的日志消息可能有助于验证是否在守护程序模式下正确加载。这不是原因，它们本来可以在原来的位置工作。通过将它们移到内部，它们实际上被忽略，因为您将错误的目录路径作为
目录
的参数。使用签入，您可能会发现您的WSGI应用程序实际上不再以守护程序模式运行。嘿，Graham，为什么您认为目录路径是错误的？应用程序的python脚本实际上位于
/var/www/myapp/myapp
-是的，2 x
myapp
。谢谢
WSGIScriptAlias
中WSGI脚本的路径是
/var/www/myapp/myapp.WSGI
。这意味着目录是
/var/www/myapp
。
myapp.wsgi
是文件名组件。您似乎将它指向了与Django
wsgi.py
文件不同的文件，该文件将位于
/var/www/myapp/myapp
中。注意，重要的是
WSGIScriptAlias
中的路径，而不是Django
wsgi.py
文件所在的位置。嘿，格雷厄姆，这不是Django-这是一个完全定制的烧瓶应用程序
myapp.wsgi
知道从
myapp
子目录导入。查看文档，我没有看到任何内容表明
指令必须指向包含
.wsgi
文件的同一目录。谢谢请参阅忽略关于Django的评论，同样的问题仍然适用。使用
目录
的范围界定也适用于
WSGIProcessGroup
等指令。这是Apache工作原理的基本部分。
WSGIProcessGroup myapp
WSGIApplicationGroup %{GLOBAL}

<VirtualHost *:80>
        ServerName yourdomain.com

        WSGIDaemonProcess myapp python-home=/var/www/myapp/myapp/venv
        WSGIScriptAlias / /var/www/myapp/myapp.wsgi

        <Directory /var/www/myapp/myapp>
                WSGIProcessGroup myapp
                WSGIApplicationGroup %{GLOBAL}
                Order deny,allow
                Allow from all
        </Directory>

        ErrorLog ${APACHE_LOG_DIR}/error.log
        LogLevel warn
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

sys.prefix = '/usr'

sys.prefix = '/var/www/myapp/myapp/venv'