[features]: 分离 xinstaller 的代码和包信息

[MoYingJi]

Features Describe | 功能描述

如题

Usage Scenario | 需求背景/使用场景

更好扩展

Maybe Solutions | 可能的实现方案 - (if you are developer)

安装时寻找包并解析json...

简单写了一个json的示例 算是画了个大饼（bushi
也可以是yaml,toml之类的 哪个好用用哪个
我知道很难很复杂 代码的实现难度比我这么想到什么些什么难多了 实现不了也没关系的

{
    "info": {
        "name": "java",
        "version": "23", // 也可以直接写成 "latest"
        "size": 509704803, // 字节大小
        "url": "https://www.oracle.com/java/",
        "authors": ["Oracle Corporation"],
        "licenses": "GPL-2.0",
        // 分了下语言
        "description": "This is Java!",
        "description[zh-cn]": "你说的对 但Java是一款由Oracle开发的面向对象的编程语言",
        "description[zh-hans]": "也是简中！",
        "description[ZH_tW][Zh-hANt]": "還支持多語言同爲一條介紹 各種語言的表示形式", // 甚至还可以进一步做繁简转化？
        "description[ja]": "君の言うとおりだ、しかし、JavaはOracleが開発したオブジェクト指向プログラミング言語です"
    },
    
    // 个人在此处 将 support 和 dependencies 合并
    // 各种东西都在 dependencies 中解析 如系统、架构等
    // 部分依赖可能解析会比较复杂？
    // 各花括号做或运算(or) 花括号内做与运算(and)
    // 下面所有 dependencies 均遵守规则
    "dependencies": [
        { "windows": ">= 7" },
        { "linux": "*" }, // 可选择缩写为 "linux"
        "macosx", // 缩写 等于 { "macosx": "*" }
        { "freebsd": "todo" } // 可以这样写表示未来会支持？或者 "-"
    ],

    "check": {
        // 全部
        "*": "java --version",
        // 分平台
        "windows": "java --version",
        // 复杂判断
        "linux": {
            "command": "java --version",
            // null 表示命令不报错即通过检测 否则需要执行command(可报错/看check?)后判断check
            "check": null, // 可省略 如果未安装或未正确安装时此命令不报错但输出会不同或均报错时使用？（不知道我怎么想的
            // "version": "java --version | awk 'NR==1 {print $2}'" // 输出当前安装的版本 可能用于检查？
            // 也可以写成
            "version": [
                { "dependencies": ["pacman"], "command": "pacman -Q jdk23-openjdk | awk '{print $2}'" },
                { "dependencies": [], "command": "java --version | awk 'NR==1 {print $2}'" }
            ]
        }
    },

    "package": {
        // 按照指定的 method 安装，从上到下判断 dependencies
        "linux": [
            // command/install/upgrade 既可以写成 string 也可以写成 array
            {
                "method": "system",
                "dependencies": ["sudo", "pacman"],
                "command": "sudo pacman -S jdk23-openjdk",
                "remove": "sudo pacman -R jdk23-openjdk"
            },
            // 将 command 分为 install 和 upgrade
            {
                "method": "system",
                "dependencies": ["sudo", "apt"],
                "install": ["sudo apt install openjdk-23-jdk"],
                "upgrade": ["sudo apt upgrade openjdk-23-jdk"],
                "remove": ["sudo apt remove openjdk-23-jdk"]
            },

            // 另一种形式 但需要代码中写明每个 installer 对应的安装命令
            // 如 pacman -> sudo pacman -S %s <- %s 会被替换为 package
            // 这样也可以避免写三条相似命令来实现 install/upgrade/remove
            // installer 同时也要求了 dependencies 故可以不写
            { "method": "system", "installer": "pacman", "package": "jdk23-openjdk" },
            { "method": "system", "installer": "apt", "package": ["openjdk-23-jdk"] },

            // 若不在官方索引
            {
                "method": "system",
                "installer": "pacman", // 由 xlings 提供 pacman -U %s 命令
                "dependencies": ["x86_64"],
                "url": "https://archlinux.org/packages/extra/x86_64/jre21-openjdk/download"
                // 本来想用 file 的 考虑到一些包管不支持直接下载并安装？还是让xlings自己先下载下来再安装吧
            },
            {
                "method": "system",
                "installer": "dpkg",
                "dependencies": ["x86_64"],
                "url": "https://download.oracle.com/java/23/archive/jdk-23_linux-x64_bin.deb"
            },
            
            // 直接下载安装 简单粗暴
            {
                "method": "download",
                // "installer": "extracter", // 由 xlings 提供的默认 installer 用于解压到 path 处
                "dependencies": ["x86_64"],
                "source": ["https://download.oracle.com/java/23/archive/jdk-23_linux-x64_bin.tar.gz"],
                // 或 "skip" 跳过校验 / 不填跳过校验 / 手动强制跳过校验并警告
                // 如果是 array 数量必须和 source 一致
                "sha256sums": ["114514"],
                // 目录 作为参数传入
                // 此处可以设置默认安装目录 但可以被用户覆盖
                "path": "/usr/lib/jvm/java-23",
                // 如果不使用 installer extracter / extract 的可能代码实现
                "command": [
                    "cd /tmp",
                    "bsdtar -xf $source", // $source 会被设为下载后的文件的绝对路径
                    // 校验目录是否存在 并删除（随便写的 实际应该做更复杂的处理 如判断path是否为程序 让用户选择是否继续安装等）
                    "[ -e $path ] && { echo \"Warning: $path exists!\" && { rm -r $path || sudo rm -r $path; }; }",

                    "mv ./jdk-23/* $path || sudo mv jdk-23 $path" // 由于路径会被用户覆盖 所以应填写默认路径并使用 $path
                    // 此处不应删除 source 文件 应由用户选择 并在安装完成后由 xlings 执行
                ],
                "lua": [] // 可能用于实现复杂逻辑？我不知道lua是否支持执行string中的代码
            }
        ],
        "windows": [
            // 我对 windows 不怎么熟悉 只写了这个
            { "method": "system", "installer": "winget", "package": "OpenJDK.OpenJDK" }
        ]
    }
}

Additional context | 额外补充

甚至可以开个仓库专门存json？（

[Sunrisepeak]

这个功能是目前要打算做的, 做一个包的索引库, 或许可以直接用lua文件做包描述文件。然后顶层设计 看需要哪些描述项, 再根据这个设计文件结构

[Sunrisepeak]

• [Release Plan]: 稳定版本0.0.1规划 | 欢迎留言交流讨论 #38 | 之前有在正式的0.0.1版本规划中提到这个功能

你对这个开发感兴趣吗? 如果感兴趣我可以建一个群一起交流讨论

[MoYingJi]

很多人其实不太懂 lua 比如我 根本就没接触过 更不用说参与编写包信息甚至xlings开发了（
lua 中有很多 return try 应该也是用于判断是否安装的了 我觉得 install 后判断是否安装不应该可以直接调用 installed 吗
代码自由度确实高 且不麻烦 但很多时候格式不统一 很多重复代码判断等？格式也不统一 个人觉得还是统一信息汇总交给xlings比较好？

[Sunrisepeak]

lua不需要额外学习, 可以把他当成一个描述想法的工具。只要会一点编程基础或学过一门其他的编程语言(本质是编程的思维/思想)基本就可以使用了, 对于特殊的语法用的时候再查文档 或 用chatgpt/大模型之类的来辅助 基本问题不大 而对于 return try 这种其实不常这样写, 只是为了实现一个特殊功能下想出来的一个小技巧 来避免windows下的异常情况。总之lua基本看一下基础教程就能写了 这个完全不用担心的

[Sunrisepeak]

关于重复判断, 这个只需要把架构设计好, 通用的部分放到框架里去就可以了。至于现在xlings里有一些地方代码的实现比较乱, 主要是先把功能做出来, 然后在调整和设计架构的方式来做的。(lua调整起来也比较快

[MoYingJi]

可以试试？我b私你了（

[Sunrisepeak]

可以试试？我b私你了（

群号: 1006282943

[MoYingJi]

群号: 1006282943

搜不到（

[Sunrisepeak]

[Sunrisepeak]

#49