[features]: Attempt of Unification of Utility And Operation Instantiation

[lvyuemeng]

Features Describe | 功能描述

Current runtime is quoted by every feature, and spread out over many files includes common.lua, xlings.lua, parts of utils.lua, platform.lua. It could be parts of cli, runtime, system separation.

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

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

1. Segregate as cli, runtime, system and much more by utility.
2. cli: Parse input; call a certain functionality or feature.
3. runtime: provide infos of current execution, such as home, cwd, xlings_home; control the current env or index.
4. system: provide OS, Arch, PM info with their interaction.
5. env: handle version and path.
6. package: package_index and related utility.

Currently, there are two ways of separation, first as functionality, second as cli args. If we want to emphasize on functionality, the callee should be each functionality as args rather than install, uninstall, it's vague whether uninstall package or uninstall xlings itself. So a better choice is to separate by functionality, and abandon the verb args (xlings xim *args*). If we want to extend many, such segregation seems unavoidable.

For example:

-- cli
-- -- xim
-- -- other functionality...
-- runtime
-- package
-- other base...

Additional context | 额外补充

[lvyuemeng]

system

1. system package manager: moving pm_wrapper to it. (postpone implementation)

• system deps control.

2. console control. (set temporary local console.)
3. add OS, arch semantics.
4. path modification

version

1. version semantics.
2. version manager connection.
3. accept info from package.
4. version control ops:
   • transfer installation strategy.
     • if vm handled version manager.
     • if self_vm handled self-versioned.
     • if native no need.
     • if prebuilt handled env info.

package #54

Prefer plugin, remove index for manual version maintaining

1. Installation strategy semantics.
   • self_vm
   • vm (handled by preinstalled version manager)
     • list version managers.
   • native (extract env info from installation script)
   • prebuilt
     • fetch
     • extract
     • config
     • env_set
2. package plugin (remove manual maintaining).
   • example:
     • rust
       • Possible files for private operation
       • index/src (interfaces, list below.)
   • register
     • register()
   • env
     • detect_version_files() -- local version requirement detection
     • fetch_version() -- collect version info online.
     • locate_exec()
   • download
     • fetch_prebuilt()
   • installation/remove
     • install_self_vm()
     • install_vm() -- check and install vm first.
     • install_native()
     • install_prebuilt()

env

1. accept info from package, version for ops.
2. env strategy in priority:
   • vm
     • including self version manager (for example: bun, rust)
   • shims
     • accept locate_exec from package:
       • run version
       • detect local proj
         • if version conflict, resolve to change
     • path
     • script
   • symlink (not recommend)
     • path
     • ops
   • activation (local proj if necessary)

[lvyuemeng]

Native:

Definition: The package is installed directly from source or binaries without any version management.

Use Case: Tools that do not require version management or are system-level dependencies.

Example: gcc, make, or system utilities.

Version Manager:

Definition: The package is managed by a version manager (e.g., nvm for Node.js, rvm for Ruby).

Use Case: Tools that require multiple versions or isolated environments.

Example: node, ruby, python.

Prebuilt:

Definition: The package is downloaded as precompiled binaries and installed directly.

Use Case: Tools that are distributed as binaries and do not require compilation.

Example: docker, vscode.

Self-Versioned:

Definition: The package comes with its own version manager (e.g., Rust with rustup).

Use Case: Tools that bundle their own version management system.

Example: rust, bun.

[lvyuemeng]

Runtime

Path Storage

• home (home path)
• cur (work path)
• store
  • root (the store path of infos that list below)
  • bin_dir
  • cache_dir
  • temp_dir
  • plugin_dir
  • tools_dir (store remote versions and portable package)

Construct a test sandbox...(May need other Lua package aid)

Config
User config only.

[lvyuemeng]

CLI

Utils[Advanced]

• install graph
• version list
• progress bar
• users interaction (including prompt, parse info)
• style control
• debug info
• plugin register

Cmds[Advanced]
Format: xlings [module] [ops] [target]

• xim (move XPackage ops to xim itself, because it's related to IO ops)
  • accept various args to define ops
  • install by
    • source
    • install strategy
  • update by installation type
  • uninstall by installation type
• xvm
  • ...

[lvyuemeng]

shims

env
shims script or binary content:

• read shims registry (wait for construction...)
• determine version based on config
• interpolate cmds with real env path and name

create shims:

• ensure self integrity
• create shims script or binary
• place at the entry path

shims registry

• name
  • name callee (the real name called in env)
  • before args
  • after args
  • env vars

[Sunrisepeak]

TODO

• [Release Plan]: 稳定版本0.0.1规划 | 欢迎留言交流讨论 #38

[lvyuemeng]

The identification is too much from current view.

It's always pleasant to reply on OS native installation first to avoid confiliction, rather we then use a isolated prebuilt installation or script installation for certain apps.

However, manage all possible installation is impossible and require a higher permissions. It's suggested a isolated env control. The key is to manage xlings environment export in PATH. The external state should be minimal to access. Version management is connected with daily update extracted from a custom script, which should be managed by each package format only, but it's a toil.

[lvyuemeng]

@Sunrisepeak Currently, I'm developing a crate called pulith as deps for external resource manager, including package manager. Here the link: pulith. The stack can be migrated.