[features]: Package Manager Integration and Categorized

[lvyuemeng]

Features Describe | 功能描述

As title.

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

Clean and selectable.

1. There's no need to list C# and dotnet, because C# is contained in dotnet, also F#, Visual Basic... I guess same problem occur in other packages.
2. The connection of each package is missing, for example, rust contains its own version, package manager, so it's independent. As for Node, C, C++, there's a missing exposition for its underneath manager. (fnm could be used on Windows, so for nvm for Windows, we should give the freedom for users.)
3. There's a fusion of langs and tools, langs and its version manager(npm is installed with node, but pnpm isn't).

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

1. Extract info from category of package to categorize.
2. We need to detect env in each execution of xlings. (Construction of env. Index shouldn't take over the role of env management)
3. Construction of relation of package for its (general) parents or so (the relation could be general and hierarchy), therefore give the freedom of choosing its manager and detection. (A notion here: node, deno, bun is runtime of js, but it's independent, so doesn't collide, however, nvm and fnm may collide, so parents of a package must be single in a certain env)

Additional context | 额外补充

[Sunrisepeak]

pre-v0.0.2 already support some features:

• 1.string match when search installer/package

• 2.merge alias to ref's version

[lvyuemeng]

@Sunrisepeak
It's not what I mean. I mean here, every relation of package is vague, not the sibling of a package.
For example, fnm and nvm are both the version manager of node, but node is independent of these version managers.
And if I change the version by fnm or nvm, could xlings detect that?

[Sunrisepeak]

@Sunrisepeak It's not what I mean. I mean here, every relation of package is vague, not the sibling of a package. For example, fnm and nvm are both the version manager of node, but node is independent of these version managers. And if I change the version by fnm or nvm, could xlings detect that?

now, nodejs is already installed by binary package.

• https://github.com/d2learn/xim-pkgindex/blob/main/pkgs/n/nodejs.lua

[Sunrisepeak]

xvm module will be easy to implement and control when use binary pcakge to install nodejs(or other

[lvyuemeng]

xvm module will be easy to implement and control when use binary pcakge to install nodejs(or other

You can't always suppose users do what you want to do. Users may use their own version manager or handle it manually. You need to suppose the worst condition.

[Sunrisepeak]

now it is not support to detect fnm/nvm's node info. maybe whereis can get node's path info if it is installed by fnm/nvm

[lvyuemeng]

Another problem I mentioned is the collision of (general) parents of a package. (not a sibling of a package), nvm and fnm surely control node, and independent, but only one can exist in same env. (You don't want a multiple version manager in a same env.)

That means, if whole packages can be viewed as a multiple combination of trees. For every tree, each vertex has a relation map for parent, sibling in this tree. The restriction would be clear for a manager to be a parents vertex, a package would be a virtual vertex contains its siblings. It would be clear that it must have only one parents

[lvyuemeng]

A radical implementation is to preinstall version manager and call the version manager first. The package could transfer a part of role to version manager and maintain a stronger connection (We don't need to maintain a version list for these packages, because they can do better than us, all we need to do is to detect, resolve collision of these managers rather than packages, and partially call those managers.). For those package without version manager or unneeded retain the same.

awesome-version-managers
There are multiple and even generic version managers, which could be as a reference.

[lvyuemeng]

A possible solution for manager in proto:

pub enum SystemPackageManager {
    // BSD
    Pkg,
    Pkgin,

    // Linux
    Apk,
    Apt,
    Dnf,
    Pacman,
    Yum,

    // MacOS
    #[serde(alias = "homebrew")]
    Brew,

    // Windows
    #[serde(alias = "chocolatey")]
    Choco,
    Scoop,
}

pub fn detect() -> Result<..> {}
pub fn config() -> Result<..> {}

Command control:

pub enum CommandType {
    /// Installs a system dependency.
    InstallPackage,

    /// Updates the registry index.
    UpdateIndex,
}

/// The CLI argument format for enabling interactive mode.
#[derive(Clone, Debug)]
pub enum PromptArgument {
    /// Does not support interactive.
    None,
    /// Enables interactive mode: `-i`
    Interactive(String),
    /// Disables interactive mode: `-y`
    Skip(String),
}

/// The CLI argument format for including the package version to install.
#[derive(Clone, Debug)]
pub enum VersionArgument {
    /// Does not support versions.
    None,
    /// In the same argument with the package name: `pkg=1.2.3`
    Inline(String),
    /// As a separate argument: `pkg --version 1.2.3`
    Separate(String),
}

/// Configuration for a specific package manager vendor.
/// The fields define commands and arguments for common operations.
#[derive(Clone, Debug)]
pub struct PackageManagerConfig {
    /// Mapping of command types to CLI arguments.
    pub commands: HashMap<CommandType, Vec<String>>,

    /// How interactive/prompt arguments are handled.
    pub prompt_arg: PromptArgument,

    /// List of commands that support prompts.
    pub prompt_for: Vec<CommandType>,

    /// How version arguments are handled.
    pub version_arg: VersionArgument,
}