[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,
}

[lvyuemeng]

A possible solution of config

-- class define
-- runtime.config (contains local, global etc..)
config = {
   possble setting
}
-- runtime.configFile (exist? global? local?)
-- runtime.configManager (detect and manage)

[lvyuemeng]

Refactor package index referring proto:

-- dir
-- rust
-- deno
-- bun
-- ...

-- every dir possibly contains:
-- rust
-- -- possbile files for private operation
-- -- index/src (interface)

-- api design in package referring to `proto`:
-- output: json file parse

-- register
register_tool()

-- env
detect_version()
load_version()
locate_executable()

-- installation
download_native()
downlaod_prebuilt()

[Sunrisepeak]

xvm shouldnt process system's package-manager directly. install/uninstall can use xim to complete, xvm only need to focus on version control for software and env-workspace.

example

• xvm can create a env-workspace independent with host
• create a workspace by xvm_workspace.lock

xvm target version

xvm new workspace

xvm enter workspace

(xvm-module consider to write by rust)

[lvyuemeng]

xvm shouldnt process system's package-manager directly. install/uninstall can use xim to complete, xvm only need to focus on version control for software and env-workspace.

That's mean you abandon the installation by system package manager, so what you have done in previous construction? xvm workspace is a virtual env style, possibly better choice is to detect local project and use shim for env control, or user can directly call activate for local project.

Here, version semantics is necessary and unrelated to xvm, xim, it's just a part of basic functionality. And I already mentioned in #55, including installation semantic. And I guess you're too optimistic about current xim feature, it isn't well-suited regarding the coupling of system package manager and deficiency in version, env control. It's not only for xim, rather because the common functionality shared by those what you think of interfaces, such as xvm, xim.

[Sunrisepeak]

xvm shouldnt process system's package-manager directly. install/uninstall can use xim to complete, xvm only need to focus on version control for software and env-workspace.

That's mean you abandon the installation by system package manager, so what you have done in previous construction? xvm workspace is a virtual env style, possibly better choice is to detect local project and use shim for env control, or user can directly call activate for local project.

installation by system package manager, they are not support multi-version management(core reason), but xpm can do, because it can track installation path. (use symlink or xlings_bashrc to ref to target version)

1. install software: pmwrapper, xpackage/xpm
2. version management: xpackage/xpm, (pmwrapper/system-pm is so hard to implement

[lvyuemeng]

installation by system package manager, they are not support multi-version management(core reason), but xpm can do, because it can track installation path. (use symlink or xlings_bashrc to ref to target version)

You could isolate the part as I said and postpone that. Actually proto implement that, even they don't directly use. There may exist a confliction between user native installation and xlings behavior, you can't guarantee that always. For current situation, isolating the pm_wrapper, as you said, custom script installation is suitable. Then, use shims or symlink as env management, but as I suggest that, env control need to be integrated to package itself, because it's unique to every package.