Open matyhtf opened 5 years ago
很棒的项目 如果能把 PHP 的包 打包成对 PHP 解释器无依赖的二进制执行文件 放 Linux 服务器上直接运行 那就更棒了 可以把解释器打包进去
@wujunze java
也离不开jvm
记得看到过 node 有个项目 可以把 node 包打包成 不依赖 node 解释器的 二进制文件 他也是把解释器打包进去的 可以参考一下
看懂了,spm就是php-fpm(php-spm) + composer = swoole + composer。这样很好哇更符合行业标准更规范吧
有些项目是前后一起的 有node的 package.json
同名有可能出现冲突呢 😄
@wujunze 那个应该只是把node
本身也打包进去了。
@inhere 不如叫 swoole.json ?
panda的建议不错,但是这个不应该是spm做的事,可以单独起一个项目做这件事,spm专注于包管理,其他的包来提供其他的能力,比如说typephp😀
@maryhtf 是把 node 打包进去了 @qxhy123 建议不错 单独起一个项目 职责更加清晰
不是很明白,和composer
相比,解决了什么问题。spm
是用来管理启动时和WorkerStart
时加载的包吗?
不建议使用 package.json
做为依赖管理的文件名,因为和 npm
的 package.json
例如 laravel 里会使用 npm
管理前端文件,文件名就为 package.json
推荐使用 swoole.json
spm.json
, spm-swoole.json
swoole-package.json
spm-package.json
不建议使用
package.json
做为依赖管理的文件名,因为和npm
的package.json
例如 laravel 里会使用npm
管理前端文件,文件名就为package.json
推荐使用swoole.json
spm.json
,spm-swoole.json
swoole-package.json
spm-package.json
附议,另外如果完全兼容composer
,也可以考虑直接使用composer.json
既然完全兼容composer,希望可以直接使用composer.json
Composer本身的scripts字段就能实现服务管理,然后同时存在多个版本的场景是什么?版本管理的目的之一就是根据依赖选择最合适的唯一的版本。
我觉得这个项目的核心没有出来,不用phar继续用文件也能实现同样的事情,版本管理用户也不会使用多版本,想要换成某个版本只需要在composer.json上指定对应的版本即可,启动命令可以通过Composer的scripts完成。
如果不考虑多版本的话完全可以在 composer
里做插件来实现,composer
的插件机制很强大。
例如这种就是通过 composer
通过插件的形式管理和安装 npm
包的
https://github.com/fxpio/foxy
yii 3.0 使用的就是这个
直接兼容phar+composer是不是就可以了,这样升级\学习成本就会少很多。至于服务化是swoole独有的
期待早日支持socket.io ,自定义定时任务和兼容rpc,如grpc,thrift等
期待早日支持socket.io ,自定义定时任务和兼容rpc,如grpc,thrift等
这些都是自己封装的啊,swoole哪来这么多精力做这么多事 😄
phar包中 realpath可能会有问题
感觉没有什么用
期待早日支持socket.io ,自定义定时任务和兼容rpc,如grpc,thrift等
这些都是自己封装的啊,swoole哪来这么多精力做这么多事 😄
那也要给出自定义增加进程的方式啊,我添加个addprocess到 serve上,启动就变成3个进程了,基本无法管理进程的,都不知道咋回事,感觉不可靠
npm start
就可以启动包内的服务。
npm start 实际执行的是npm run start,对应package.json中script start后面自定义的命令;并不是npm去启动的服务,依赖其他包提供的web server,比如webpack-dev-server
期待早日支持socket.io ,自定义定时任务和兼容rpc,如grpc,thrift等
这些都是自己封装的啊,swoole哪来这么多精力做这么多事 smile
那也要给出自定义增加进程的方式啊,我添加个addprocess到 serve上,启动就变成3个进程了,基本无法管理进程的,都不知道咋回事,感觉不可靠
文档里面都有,添加自定义进程挂到master下面。socket.io rpc 可以参考https://github.com/lizhichao/one
做成一个 symfony console 工具包就可以了,包管理还需要集中管理的服务器。
现状
由于
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
处理phar 包
spm
将提供phar
包管理功能的功能,类似于java
的jar
包,依赖某个组件,如easyswoole
或swoft
时,可以在命令行中执行或者修改
package.json
增加:这将会下载一个
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
对象。包含了传入的一些参数。main
函数中抛出异常,可以终止启动swoft/framework
被引入到其他包时,main
函数将变成一个内部函数不会被执行main
函数前,所有依赖的phar
包都会被提前include
进来,也可以通过配置,指定某些包在WorkerStart
时载入关闭、重启和重载入: