Description
现状
由于php官方主流的php-fpm短生命周期存在很多限制，很多高级的用法在无法应用于php程序中。swoole支持常驻内存，应用程序可以使用更多高级的用法。
其中包管理composer的设计就是一个典型的例子。
碎片化
vendor目录必须中均为单个php的文件，java语言中所有的包均为jar，虽然php也提供了phar打包机制，但使用的场景非常有限。c/c++程序采用的是 *.so或*.dll作为一个组件（包）。多个版本可以共存，如：libswoole.so.4.2.13、libswoole.so.4.2.12，应用程序可根据需要链接到不同的版本。
服务管理
composer不支持服务管理功能，实际上普通的php程序也没有服务的概念，全部由php-fpm来是实现服务。而swoole启动的进程本身就是服务，应该自带服务管理的功能。node.js的npm就是一个很好的例子，npm start 就可以启动包内的服务。
SPM
基于上述的原因，我们计划实现一个swoole package manager的程序。来提供更高级的包管理器能力。但由于composer几乎接近php的标准，生态非常完善。因此我们会完全兼容composer。
兼容
-
spm将100%兼容composer，基于composer进行二次开发。在保证composer所有功能可用的前提下，增加更多swoole特有的高级功能。可以直接将spm作为composer来使用 -
spm将内置于swoole boot二进制包中，无需额外安装，可直接使用 -
在
composer.json中的配置，使用composer基础模块来处理 -
在
package.json中的配置，使用spm处理
以下文档中提供的配置全部在
package.json中
phar 包
spm将提供phar包管理功能的功能，类似于java的jar包，依赖某个组件，如easyswoole或swoft时，可以在命令行中执行
spm include swoft/framework可以使用
-g参数安装到全局目录中，其他工程中会有限查找全局目录中是否有满足版本需求的包
或者修改package.json增加：
"require": {
"swoft/framework": "^2.2"
}这将会下载一个swoft/framework.phar.{$version}的包。如：./vendor/spm/swoft/framework.phar.2.0.3
spm主要借鉴java的maven进行组织composer包可以使用spm build-package直接打包为phar格式的spm包
服务管理
使用spm start [-- <args>]可以启动当前包中的服务。
spm会根据当前包在package.json中定义的命名空间，在该命名空间中查找main函数，并执行
如：package.json中定义了namespace为Swoft\Framwork，spm将执行Swoft\Framework\main()参数。
参数为一个Args对象。包含了传入的一些参数。
{
"name" : "swoft/framework",
"namspace" : "Swoft/Framework",
"description" : ""
}namespace Swoft/Framework;
function main(Args $args) {
//code ...
$server->start();
}- 在
main函数中抛出异常，可以终止启动 swoft/framework被引入到其他包时，main函数将变成一个内部函数不会被执行- 执行
main函数前，所有依赖的phar包都会被提前include进来，也可以通过配置，指定某些包在WorkerStart时载入
关闭、重启和重载入：
spm stop
spm reload
spm restart