[features]: xinstall: 索引库中的包文件结构定义

[Sunrisepeak]

Features Describe | 功能描述

当前包结构

function support()

end

function installed()

end

function install()

end

function uninstall()

end

function deps()

end

function info()

end

索引库中的包文件结构定义

Usage Scenario | 需求背景/使用场景 - 要思考的问题

• 版本差异
• 不同系统的差异
• 包名重复问题
• 哪些部分交给框架来做, 哪些部分由包安装文件实现者来做?

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

temp solutions

function cmdprocessor(target, cmd) {
    xpkg = index_manager.load_pkg(target)
    pm_executor = pkg_manager_service.create(xpkg.get_pm_name())
    if cmd == install then
        pm_executor.install(xpkg)
    else
    ....
}

Additional context | 额外补充

[lvyuemeng]

May be a form with certain interface and maintains a proper registry for every package.

-- os_manager.lua
local OSManager = {}

function OSManager:new(os_type)
  local ins = {
     os_type = os_type,
     pm = {}
  }
  setmetatable(ins,OSManager)
  
  -- logic to adapt manager(may be multiple for extension)
  -- We may expect a certain choice for package manager or retry-logic by varying package manager.

-- package_manager.lua
local PM = {}

-- certain_manager.lua
local Winget = setmetatable({}, PM)
Winget .__index = Winget

-- package.lua
local Package = {}
Package.__index = Package

function Package:new(format input)

-- We may expect a raw manager for a bunch of certain packages itself to control at least own installation.(such as many langs.)
-- We may need to maintain caches for users.

-- package_registry.lua
local packageA = Package:new({
    "packageA",
    "1.0.0",
    { "packageX" }, -- dependencies
    {
        supported_os = { "linux", "windows" },
        supported_managers = { "apt", "winget","raw" }
    }
    -- rest of logic
}),

It probably overengineer for now, or I digress if I misunderstand something.

[MoYingJi]

我正在尝试的是类似于这个
What I am trying is like this

-- pkg/jdk21.lua
function info() return {
    -- TODO
    name = "jdk21",
    provides = { "java=21" },
    deps = {},
    desc = { en = "...", zh_hans = "..." },
} end

function version_of()
    import("installer.base.utils")
    local ok = utils.try_run("java --version").ok
    if not ok then return nil end
    return ok:spilt('\n')[1]:spilt(' ')[2]
end

function package() return {
    { manager = "pacman", package = "jdk21-openjdk" },
    { manager = "apt", package = "openjdk-21-jdk" },
    { manager = "winget", package = "Oracle.OpenJDK.21" },

    {
        deps = { "windows", "x86_64" },
        sources = { "https://download.oracle.com/java/21/latest/jdk-21_windows-x64_bin.zip" },
        sha256sums = { "6cce98ce38b86737c63912fd1df9ecfee1fe209ab08c0e1e16500f054e67de48" },
        default_path = "C:\\Program Files\\Java\\jdk-21",
        commands = function()
            print("无 winget 情况下的安装")
            print("install without winget")
        end
    }
} end

function finally() end

其中我合并了 os 和 manager 因为我个人觉得大部分情况一个包管仅为一个系统服务
I merged os and manager because I personally think that usually one package manager only serves one system

我看了你的回复 我觉得其中的 info() 可能可以作为注册或索引？
I have read your reply, and I think the info() in it may be used for registration or indexing?

supported_managers 被删除 因为这里设计了多重安装方式 会从上到下判断 deps 和 manager 进行安装
索引时可以将 package 中的 manager 和 deps 合并为一个 deps 数组放在注册表中以便快速确认
supported_managers has been removed because multiple installation methods are designed here to determine the installation of deps and manager from top to bottom
When indexing, the manager and deps in the package can be merged into a deps array and placed in the registry for quick confirmation

这里的 version_of 是确认是否安装的第二方式 因为包管中也有一个 version_of(package_name) 用于判断是否在此包管中安装了
The version_of here is the second way to confirm whether it is installed, because there is also a version_of(package_name) in the package to determine whether it is installed in this package

[lvyuemeng]

@MoYingJi

1. Combination of OS and PM is fine. Due to your fine grain preference(I reminds of current multiple package managers in windows(winget, scoop, chocolatey), so it would be awkward if you merge the design).
2. info() could be a registry. The design here is package itself should be its manager(it could be further discussed for which functionality is suitable like version validation or OS support etc.)
3. version_of() is suggested in a style as above.

Such ecosystem about package management is overlapped with X-cmd in linux and UniGetUI in windows. Especially X-cmd contains a much larger functionalities.

[Sunrisepeak]

举几个 包管理器的 包描述文件的 最简实现的样子 - GPT

包描述文件是定义软件包属性和依赖关系的重要组件。不同的包管理系统如 Debian 的 APT、RedHat 的 YUM、Node.js 的 npm 等，都有自己的包描述格式。以下是几种不同包管理器的包描述文件的最简实现示例：

1. Debian (APT) 的 control 文件

control 文件是 Debian 软件包中的一部分，位于 DEBIAN 目录下，用于描述软件包的基本信息和依赖关系。

Package: example
Version: 1.0-1
Section: base
Priority: optional
Architecture: amd64
Depends: libc6 (>= 2.7), libncurses5 (>= 5.6-7)
Maintainer: Example Maintainer <maintainer@example.com>
Description: A simple example package
 This is a longer description of the example package.

2. RedHat (YUM/DNF) 的 spec 文件

spec 文件用于 RPM 包，描述了如何构建包以及包的元数据。

Name:           example
Version:        1.0
Release:        1%{?dist}
Summary:        An example package

License:        GPL
URL:            http://www.example.com
Packager:       Example Maintainer <maintainer@example.com>

Requires:       ncurses, glibc

%description
This is an example software package that demonstrates packaging.

%prep
%setup -q

%build
make %{?_smp_mflags}

%install
make install DESTDIR=%{buildroot}

%files
/usr/bin/example
/usr/share/doc/example-1.0

3. Node.js 的 package.json

package.json 文件是 Node.js 项目的核心，包含了项目的依赖、脚本、版本等信息。

{
  "name": "example",
  "version": "1.0.0",
  "description": "An example Node.js package",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "Example Maintainer <maintainer@example.com>",
  "license": "ISC",
  "dependencies": {
    "express": "^4.17.1"
  }
}

4. Python 的 setup.py

Python 使用 setup.py 文件进行模块打包，该文件使用 Python 代码来描述包的属性。

from setuptools import setup, find_packages

setup(
    name='example',
    version='1.0.0',
    description='An example Python package',
    author='Example Maintainer',
    author_email='maintainer@example.com',
    packages=find_packages(),
    install_requires=[
        'requests>=2.22.0'
    ],
)

这些示例展示了不同环境中包描述文件的基本结构和必要字段。每种包管理器都有其特定的格式和要求，设计包描述文件时需要遵守相应的规范。

[Sunrisepeak]

maybe one version align to one package file is better

• dependencies change
• maintainer change
• license change

example: java from sun to oracle

---

cargo

[lvyuemeng]

Info variation could be recorded in as a sub-construction of Package itself, if the main functionality of a package doesn't change, then Package won't need to duplicate.(Package should be a self-manager.)

[MoYingJi]

function package() return {
    { manager = "pacman", package = "jdk$version-openjdk" },
    { manager = "apt", package = "openjdk-$version-jdk" },
    { manager = "winget", package = "Oracle.OpenJDK.$version" },
} end

对于不同版本 但包信息基本相同的 可以使用 $version 代替版本？
version 也应该改为
Can I use $version instead of version for different versions but the package information is basically the same?
The version should also be changed to something like this

function info() return {
    name = "jdk",
    versions = { "8", "11", "17", "21" },
} end

但也可以同时存在多个 jdkxx.lua 管理变化较大的版本
However, it is possible to have multiple jdkxx.lua at the same time to manage the more changed versions.

-- jdk_1_x.lua
function info() return {
    name = "jdk",
    versions = { "1.7", "1.8" },
} end
install_method_a()

-- jdk_17_21.lua
function info() return {
    name = "jdk",
    versions = { "17", "21" },
} end
install_method_b_different_from_a()

甚至这两个文件可以由不同维护者维护
Even these two files can be maintained by different maintainers

我想这可能是一种解决方案？
I think this might be a solution?

[lvyuemeng]

That's close to what I mentioned.

maybe one version align to one package file is better

• dependencies change
• maintainer change
• license change

here Package should handle this. Unless the whole functionality or the installation of a package changes, Package shouldn't duplicate. (certainly caches of users needn't to contain all of this, only useful info.)

[Sunrisepeak]

common file + diff file (metadata), maybe simple is better

javabase.lua

-- other interface

function info()
    return {
         .....
    }
end

java8.lua - diff file for javabase

-- ...

-- reuse for javabase.lua
inherit(*.javabase)

-- diff
function info()
    local info = javabase.info()
    info["version"] = "8.0.0"
    info["otherChangedLable"] = "new ..."
    return info
end

[MoYingJi]

但这样确实会增加一些索引和搜索时的困难
也为编写不存在与官方索引的软件包信息时增加了难度
现在要考虑系统、包管、版本、架构等
若现在系统、包管理、架构将会合并为 deps 参数 也会为脚本中这三者的判断增加难度和迷惑性

But this does add some difficulty when indexing and searching
It also makes it more difficult to write information about packages that don't exist with the official index.
Now to consider the system, package management, versioning, architecture, etc.
If system, package management, and architecture will now be combined into the deps parameter, it will also make it harder and more confusing to determine all three in scripts.

[lvyuemeng]

但这样确实会增加一些索引和搜索时的困难 也为编写不存在与官方索引的软件包信息时增加了难度 现在要考虑系统、包管、版本、架构等 若现在系统、包管理、架构将会合并为 deps 参数 也会为脚本中这三者的判断增加难度和迷惑性

But this does add some difficulty when indexing and searching It also makes it more difficult to write information about packages that don't exist with the official index. Now to consider the system, package management, versioning, architecture, etc. If system, package management, and architecture will now be combined into the deps parameter, it will also make it harder and more confusing to determine all three in scripts.

The searching and indexing events is only related to users info, all above is contained in xlings itself.
And I didn't mention that we need to pack all things to deps for usuage.