前几章节我们有讲到，Pip 是一个命令行程序。既然它是用 Python 实现的，那么在 Python 代码中我们就可以通过 import pip 导入它

但对于这种使用方式，就不能够使用 pip 的内部 API，有几个原因

1. pip 代码自我假定只能控制程序的全局状态，Pip 管理诸如日志系统配置或标准 IO 流的值之类的事情，而不考虑用户代码可能会受到的影响

2. Pip 的代码并不是线程安全的，如果我们在一个线程中运行 pip，则无法保证我们的代码或 pip 可以按预期工作

3. Pip 一旦完成工作，处理过程将立即终止，它不需要处理其它代码在该点之后继续运行的可能性，因此（ 例如 ）在同一进程中调用 pip 两次可能会出现问题

以上三点并不意味着 pip 的开发人员原则上反对 pip 可以用作库的想法，它们只是想表达这不是它们被设计的使用方式。

如果为了可以将 pip 做一个库来使用，意味着要重新设计，设计一个可用，稳健和稳定的 API，同时又要在多个版本的 pip 中都能保持可用，这将是一项很大的工作，目前，pip 开发团队根本没有资源来考虑这样的任务

这在实践中意味着 pip 内部的所有内容都被视为实现细节，对于实现细节，我们可能随时会更改，即使作为库的名称为 pip 这一惯例我们也可能会随时更改，且我们不会给出任何通知和警告，尽管我们 pip 开发团队会尽最大的可能来保证不会破坏任何兼容性，但这不是理由，所有内部 API 都可以随时更改，出于这个原因，意味着我们并不会尝试去修复 pip 不支持的使用方式所产生的问题

还有一点值得注意的是，应该谨慎处理在正在运行的 Python 进程中将软件包安装到 sys.path。import 系统会缓存某些数据，并且在程序运行时安装新程序包可能并不总是按预期运行。虽然在实践中，很少有问题，但仍需注意

说了这么多，如果你仍执意要在诚寻中运行 pip，这里有一个备用的方案

最可靠和完全支持的方法是在子进程中运行 pip，使用标准库中的 subprocess 模块可以轻松的完成此工作

subprocess.check_call([sys.executable, '-m', 'pip', 'install', 'my_package'])

如果需要进一步处理输出，请使用 subprocess 模块中的其他 API

reqs = subprocess.check_output([sys.executable, '-m', 'pip', 'freeze'])

如果你不想使用 pip 的命令行功能，而是尝试编写一些适用于 Python 包，元数据或 PyPI 的代码，那么你应该考虑提供这种能力的其它受支持的包，我们这里推荐几个

1. packaging，提供了一些函数用于获取一个标准的包的元数据 ( 版本，依赖，等等 )
2. setuptools 中的 pkg_resources，提供了一些函数用于查询在该系统上已经安装的包
3. distlib ，打包和分发实用程序 ( 包含了与 PyPI 交互的功能 )