标准CloudFoundry python buildpack允许您通过指定对以下文件的依赖关系来部署应用程序

要求.txt

您可以在此处添加numpy，它将在没有任何问题的情况下安装它。但是，如果您输入任何依赖于numpy的包，buildpack将失败，像这样：

要求.txt

显然buildpack不准备安装诸如numpy之类的预要求。以上输出来自PythonBuildPack版本1.6.25。在撰写本文时，最新版本是1.6.28。但是，即使指定了最新的版本，淘客app开发，这种行为也基本相同。

有些人已经派生出了这个buildpack的旧版本，而且从来没有费心更新他们的派生来包含之后所做的更改。

所以我的问题是如何在标准buildpack上提供这种依赖的用法。

经过大量的挖掘我遇到了一个我不知道的关于python构建包的文档。它应该能够像部署Anaconda或Miniconda一样部署您的应用程序。不过，上面说的只是使用文件环境.yml.

因此解决方案将包括以下步骤：

注意：根据我的经验，我必须添加icu，以避免在启动过程中出现库链接错误。nomkl也是为了减少conda在云中的环境所占用的磁盘大小而存在的。

这将像您习惯于使用以下conda命令一样工作：

这让您感觉不那么"容易出错"，云淘，并且可能会使您的应用程序像在conda环境中运行一样工作上面的命令。

如果您不需要考虑云环境与您自己的本地环境之间的各种差异，那么发布python应用程序的方法也是正确的。

一旦这个文件就位，你必须改变主意清单.yml开始使用cloudfoundry最新buildpack的文件：

注意：为了方便起见，大数据如何处理，我在这里加入了环境变量BP\u DEBUG。如果您在部署应用程序时遇到问题，人工智能包含哪些方面，请取消对该变量的注释，大数据汇总，它将开始提供大量信息，以便您了解正在进行的操作。

一旦执行cf推送，您将开始注意到buildpack将以不同的方式工作。

首先，它将加载miniconda:

注意：不要担心python在2.7版上。Miniconda 2.4.5.12就建在上面。而且这个python版本不是CF将用作应用程序运行时的版本。

Miniconda将根据您的应用程序来确定环境需要什么环境.yml：

is构建环境后，它将显示一个tarball列表，这些tarball将从文件系统中删除。以下是可用于您的环境的程序：

注意：签出每个tarball的总文件大小–巨大，对吗？。想想解压后需要多少磁盘空间。

软件安装到conda环境后，您将看到buildpack删除不再需要的文件，并准备运行start命令：

现在Cloud Foundry尝试启动您的应用程序。当它成功时，它会显示一些统计数据：

注意：检查这个应用程序的总体磁盘大小：1G。这就是为什么，我不得不在我的清单文件中使用2G。这就是我添加nomkl模块的原因——我没有试图弄清楚这是否真的有用。运行一个简单的python应用程序对我来说是不可接受的！