小惠珠哦

这个屌丝很懒，什么也没留下！

热门标签

OpenHarmony开发中的知识：“三方库管理工具”-ohpm_ohpm clean

作者：小惠珠哦 | 2024-07-25 01:38:36

踩

ohpm clean

ohpm作为OpenHarmony三方库的包管理工具，支持OpenHarmony共享包的发布、安装和依赖管理。

ohpm配置文件。

描述

ohpm从命令行和.ohpmrc文件中获取其配置设置。ohpm config命令可用于修改用户级.ohpmrc文件的内容。

文件

项目级配置文件：/path/to/my/project/.ohpmrc
用户级配置文件：~/.ohpm/.ohpmrc
所有 ohpm 配置文件均是 ini 格式：<key>= <value> 的参数列表

注意

命令行工具会优先读取项目级的配置文件。如果缺少某些配置项，将从用户级配置文件中读取缺失的配置项信息。
在工程任意子目录下执行ohpm命令，都可以读取到项目级的.ohpmrc配置。

注释

.ohpmrc 文件中以 # 或 ; 字符为注释符。

更新配置

执行如下命令可设置用户级配置：

ohpm config set key value

默认配置项

CA证书获取及配置

依次访问以下证书下载地址，并根据下图操作下载CA证书到本地：


https://ohpm.openharmony.cn/
https://contentcenter-drcn.dbankcdn.cn/

下载证书，请选择保存类型为证书链。

在 .ohpmrc 文件中配置 ca_files=证书路径1,证书路径2。

ca_files=D:\_.openharmony.cn.crt,D:\update.hicloud.crt

install_all

在ohpm客户端1.8.0版本的.ohpmrc中支持install_all配置，用于控制ohpm install，ohpm update，ohpm uninstall的行为，install_all在.ohpmrc文件中设置为true或缺省时：

使用ohpm install命令时，将安装工程下所有模块的依赖，与使用ohpm install --all行为一致；
使用ohpm update时，将默认更新本模块下依赖并安装工程下所有模块的依赖，与使用ohpm update --all一致；
使用ohpm uninstall时，将默认删除本模块下依赖并安装工程下所有模块的依赖，与使用ohpm uninstall --all一致。

resolve_conflict

ohpm客户端在1.5.0版本开始支持依赖版本冲突自动解决功能。只需要在.ohpmrc文件中，将resolve_conflict配置为true或缺省，即可开启该功能。依赖冲突的处理策略为：当您的项目同时依赖了某个三方库的不同版本时，ohpm将选择其中的最高版本进行安装。

注意

若某个三方库同时存在远程版本和本地版本（本地文件或源码依赖），无论本地版本的版本号是否大于远程版本，ohpm的冲突处理策略都会优先选择本地版本作为待安装的版本。

模块内依赖版本冲突

如上图所示的依赖路径中，moduleA 为您正在开发的模块，其直接依赖为 B@1.1，C@1.1。其中 B@1.1 与 C@1.1 分别依赖了 D 的两个版本 D@1.2 与 D@1.3。当您开启了依赖版本冲突自动解决功能，ohpm将会选择 D@1.3 版本作为待安装的版本，最终依赖路径被解析为下图蓝色箭头所指向的路径：

模块间依赖版本冲突

如上图所示的依赖路径中，moduleA、moduleB 为您同一项目下正在开发的两个模块，其中moduleA 依赖 B@1.1，moduleB 依赖 C@1.1，B@1.1 与 C@1.1 分别依赖了 D 的两个版本 D@1.2 与 D@1.3。当您开启了依赖版本冲突自动解决功能，并且您是使用 ohpm install --all 进行安装时，ohpm将会选择 D@1.3 版本作为待安装的版本，最终依赖路径被解析为下图蓝色箭头所指向的路径：

更新依赖版本的场景

当您希望将您某个模块的直接依赖更新成另一个版本，如下图所示，您手动将 C@1.1 更新为 C@1.2：

由于 C 更新为 C@1.2 后，不再依赖 D，若依赖 D 的版本在更新 C 版本之前已经通过 ohpm 的自动冲突处理机制锁定为 D@1.3 版本，此时 C 版本的升级将不会导致 D 的版本由 D@1.3 回退为 D@1.2，这样可以保证每一次更新都只是在上一次结果上进行影响最小的修改，最终的依赖路径将会被解析为下图蓝色箭头所指向的路径：

对于上述场景，如果希望D版本同时也回退至D@1.2版本，则需要在ohpm install之前执行ohpm clean命令清理各模块下的oh-package-lock.json5文件，以消除上一次安装结果的影响。

ohpm install命令带--target_path选项时依赖冲突处理

target_path下是hvigor在构建时根据目标产物target为各模块自动生成定制的依赖配置文件（oh-package.json5），在生成的oh-package.json5中，依赖的版本部分可能包含targetName，示例："A": "1.0.0+targetName"。

包含targetName信息的版本完整格式为：<major>.<minor>.<patch>[-<pre-release>][+<targetName>]，此时冲突处理规则如下：

1、<major>.<minor>.<patch>[-<pre-release>]部分的比较规则依然遵循上文各场景所描述的处理规则，即取版本号最大的依赖。

2、当两个版本<major>.<minor>.<patch>[-<pre-release>]部分一致时，取尾部有[+<targetName>]信息的依赖。

注意

1、当两个版本尾部均有[+<targetName>]信息，且targetName不一致时，会根据<target_path>/dependencyMap.json5中targetName是否为空进行区分处理。

当targetName空时，打印警告提示。
当targetName有值时，报错提示并终端程序。

2、当两个依赖中有一个是本地依赖时，优先取本地依赖；当两个依赖均是本地依赖时，获取本地依赖包内oh-package.json5配置的version再次按照上述规则继续比较。

限制条件说明

由于本功能尚在Beta阶段，存在如下的限制条件：

若希望解决当前项目所有模块下的依赖版本冲突，请使用ohpm install --all完成依赖安装。
若在执行ohpm update或ohpm uninstall命令后，可能会破坏项目原有的依赖版本冲突处理结果。请额外执行一次ohpm install --all命令，重新处理当前项目所有模块下的依赖版本冲突。
当本地文件（.har或.tgz后缀）依赖之间、本地源码模块依赖之间、本地文件（.har或.tgz后缀）依赖与本地源码模块依赖之间出现冲突时，ohpm自动冲突处理机制会比较该依赖内部oh-package.json5文件中version字段配置的版本号大小，版本号大的将会被安装。
注意

如难以感知本地文件或本地源码依赖中的版本号，建议使用overrides来处理冲突。

AccessToken

AccessToken是 ohpm-repo 2.1.0版本新引入的认证机制，用户通过ohpm-repo界面生成Token，并将其配置至ohpm客户端配置文件中。

在与 ohpm-repo 交互时，客户端会自动附带Token进行身份验证。该Token分两种权限等级：

只读Token允许执行info和install操作；
读写Token除了包含只读权限外，还支持publish和unpublish操作。

每位用户每种权限类型的Token最多可生成10个，首次生成时系统自动复制到剪贴板，后续不再显示完整Token内容。

如何获取AccessToken

当前AccessToken仅 ohpm-repo 支持，在 ohpm-repo 的个人中心->认证管理->AccessToken页面进行生成。

如何配置AccessToken

配置示例如下所示:


//127.0.0.1:8088/repos/ohpm/:_auth=readWriteToken
//127.0.0.1:8088/repos/ohpm/:_read_auth=readOnlyToken

其中：

//127.0.0.1:8088/repos/ohpm/ 是ohpm-repo的registry地址去除协议名的部分；
:_auth 和 :_read_auth 分别代表配置为读写Token或只读Token，readWriteToken和readOnlyToken代表Token具体的值。ohpm客户端执行info、install操作会优先使用只读Token，如果只读Token不存在才会使用读写Token。ohpm客户端执行publish、unpublish操作时只会使用读写Token。每种Token最多配置三条。

enforce_dependency_key

ohpm从1.7.0版本开始，支持在.ohpmrc文件中支持配置enforce_dependency_key，该配置项值为布尔类型，默认为false。将配置设置为true后，ohpm会校验各模块的oh-package.json5中配置的直接依赖中的本地依赖名称与其对应的包名(模块名)是否一致，若不一致会导致依赖安装失败并在错误日志中打印出不一致的依赖名称与其对应的包名(模块名)。

示例：

在MyApplication工程下存在一个名称为foo的模块，foo模块的oh-package.json5如下所示：


{
  "name": "foo",
  "version": "2.0.0",
  "description": "Please describe the basic information.",
 }

在MyApplication工程下存在另一个名称为bar的模块，且bar模块中依赖了foo模块，bar模块的oh-package.json5如下所示：


{
  "name": "bar",
  "version": "1.0.0",
  "description": "Please describe the basic information.",
  "dependencies": {
    "fee": "file:../foo"  
  },
 }

如上所示，bar模块的oh-package.json5中配置了对foo模块的依赖，并为foo模块起了一个别名为fee。当在.ohpmrc中将enforce_dependency_key配置为true时：

enforce_dependency_key=true

此时在MyApplication下执行ohpm install --all命令将打印如下错误日志，同时会中断命令的执行：


ohpm ERROR: local dependency "fee" found in "D:\DevecostudioProjects\MyApplication2\bar\oh-package.json5" does not match the actual name "foo" of its oh-package.json5
ohpm ERROR: Install failed, detail: There are some dependency names that are inconsistent with the actual package names.

若没有配置enforce_dependency_key或将其配置为false时，命令将不会被中断，同时上述错误日志的日志级别将会下调为告警日志：

ohpm WARN: local dependency "fee" found in "D:\DevecostudioProjects\MyApplication2\bar\oh-package.json5" does not match the actual name "foo" of its oh-package.json5

建议在.ohpmrc文件中配置enforce_dependency_key为true，禁止以别名的方式配置本地依赖，避免出现如下场景：

基于上述示例，在MyApplication下真的存在一个名称为fee的模块，且该模块的版本号小于foo模块，fee模块的oh-package.json5如下所示：


{
  "name": "fee",
  "version": "1.0.0",  // 小于foo的版本号2.0.0
  "description": "Please describe the basic information.",
 }

且entry模块中同时依赖了fee与bar，entry模块的oh-package.json5依赖配置如下所示：


{
  "name": "entry",
  "version": "1.0.0",
  "dependencies": {
    "fee": "file:../fee"
    "bar": "file:../foo"  
  },
 }

此时在entry的依赖树中，依赖fee存在两个版本：一个别名为fee的foo模块，一个名称为fee的fee模块，若此时开启了resolve_conflict，由于fee模块的实际版本号为1.0.0要小于foo模块的版本号2.0.0，在执行ohpm install时将只会在entry模块的oh_modules下安装以fee为别名的foo模块，而实际的fee模块则不会被安装，如下图所示：

在entry的oh_modules下会生成一个名称为fee的软连接，该链接却指向foo模块的实际路径：

如果entry实际希望依赖的是真实的fee模块而不是foo模块，则此时会导致entry无法编译成功。

odm_r2_project_root

odm_r2_project_root是ohpm客户端1.8.0新增的开关配置，默认为false，可以通过config命令或直接在.ohpmrc文件中修改其值。

当该配置为true时，若在overrideDependencyMap中配置的依赖项替换文件中存在以相对路径配置的本地依赖项时，在ohpm运行时会基于工程根路径来查找这些本地依赖项。

示例：

.ohpmrc中开启odm_r2_project_root：

odm_r2_project_root=true

overrideDependencyMap配置示例：在工程根目录下的oh_package.json5中增加overrideDependencyMap配置，如下：


{
  "overrideDependencyMap": {
     "lib1": "lib1-override-dep-map.json5",  
     "lib2": "lib2-override-dep-map.json5"
  }
}

依赖项"lib1"的依赖项替换文件lib1-override-dep-map.json5示例：


{
  "dependencies": {
    "@ohos/test": "file:./test.har"
  }
}

如上第3步所示，当odm_r2_project_root开关设置为true时，在ohpm运行时会以工程根目录为起点查找"./test.har"，比如：工程根路径为：D:\path\to\MyProject，在ohpm运行时解析得到test.har的绝对路径为：D:\path\to\MyProject\test.har。

compability_log_level

ohpm客户端从5.0.1开始新增开关配置'compability_log_level'字段，用于控制在缺少兼容性检测需要的字段时ohpm的处理逻辑。

compability_log_level字段默认赋值为'warn'，

在执行prepublish、publish命令时，ohpm会检测oh-package.json5文件中是否配置了兼容性检测需要的所有字段（compatibleSdkVersion', 'compatibleSdkType', 'obfuscated', 'nativeComponents'），下面统称 '兼容性字段'，如果未配置，则会根据日志等级打印提示或报错。

开关配置项说明

close：关闭功能，不主动检测兼容性字段。
info：检测到未配置的兼容性字段时，打印info日志。
warn：检测到未配置的兼容性字段时，打印警告日志。
error：检测到未配置的兼容性字段时，打印报错提示并中断程序。

最后

有很多小伙伴不知道学习哪些鸿蒙开发技术？不知道需要重点掌握哪些鸿蒙应用开发知识点？而且学习时频繁踩坑，最终浪费大量时间。所以有一份实用的鸿蒙（HarmonyOS NEXT）资料用来跟着学习是非常有必要的。

点击领取→【纯血版鸿蒙全套最新学习资料】（安全链接，放心点击）

这份鸿蒙（HarmonyOS NEXT）资料包含了鸿蒙开发必掌握的核心知识要点，内容包含了（ArkTS、ArkUI开发组件、Stage模型、多端部署、分布式应用开发、音频、视频、WebGL、OpenHarmony多媒体技术、Napi组件、OpenHarmony内核、（南向驱动、嵌入式等）鸿蒙项目实战等等）鸿蒙（HarmonyOS NEXT）技术知识点。

希望这一份鸿蒙学习资料能够给大家带来帮助，有需要的小伙伴自行领取，限时开源，先到先得~无套路领取！！

鸿蒙（HarmonyOS NEXT）最新学习路线