[features]: A attempt of env and package manager

[lvyuemeng]

Features Describe | 功能描述

As the title. It's an attempt, so still vague for most of the parts.

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

As I suggest, Package need to be a self-manager. In order to control env, the package need to store the variations of vendors, versions, even OS. why we don't separate to different packages? Because those packages have the same functionality and collide to each other. Package should be considered as a vertex contains all siblings.(every vertex should be depended on its parents and not its siblings.). To follow this design pattern, every feature should take its parents as an input to initialize itself.(For example, env manager should take OS manager as its input.)

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

local Package = {}
Package.__index = Package

function Package:new(name -- other inputs)
   local instance = {
        name = name,
        configurations = {} -- Will store configurations for each OS/vendor/version
    }    
    setmetatable(instance, self)
    return instance
end

local EnvManager = {}
EnvManager.__index = EnvManager

function EnvManager:new(os_manager, -- other parents)
  local instance = {
      os_manager = os_manager,
      -- os_manager should be depended on users info for implementation, so for its children.
  }
   setmetatable(instance, self)
   return instance
end

Additional context | 额外补充

[Sunrisepeak]

Package need to be a self-manager

Is it means (every)developer need to implement self-manager when write a package file

(save status?

[lvyuemeng]

Package need to be a self-manager

Is it means (every)developer need to implement self-manager when write a package file

(save status?

For example, package may need to interact with package manager, but package manager obviously don't know how to install the package unless Package provide the info. Even Package itself should contains a raw installation of itself.(Many langs, envrionment management tools provide a self-installation independent of any package manager.). We can't expect these things could be handled by the feature because it's just a tool, and don't know how to implement itself.

{   -- part of configs.
     windows: {
          winget: {}
          scoop: {}
          raw: {}
     }
     ubuntu:{
          apt:{}
          raw: {}
     }
}  -- implement all for various versions and vendors(you can't avoid by pack into all-in-one, because every versions, vendors is siblings.)

Another thing is many langs has its own version manager, you need to ponder wether to integrate that.(I personally don't recommend)

[Sunrisepeak]

1. Even Package itself should contains a raw installation of itself

many commands(install / config...) may be included for raw installation, so it is suppored by hooks function is better

2. implement all for various versions and vendors(you can't avoid by pack into all-in-one, because every versions, vendors is siblings.

do you mean all versions into one file? It may be hard to implement or package structure will be complex.

example:

-- 1.0.0 version

package = {
        name = "jdk-tools",
        version = "1.0.0",
        maintainer = "m-a",
        deps = {
            windows = {"w1", "w2"}
        },
        pm = {
            windows = {"winget", "jdk.x.x"}
        }
}

-- 2.0.0 version ( fork ...

package = {
        name = "jdk-tools",
        version = "2.0.0",
        maintainer = "m-a",
        deps = {
            windows = {"w1", "w2"}
        },
        pm = {
            windows = {"winget", "jdk.x.x"}
        }
}

package = {
        name = "jdk-tools",
        version = "2.0.0",
        maintainer = "m-google",
        deps = {
            windows = {"w1", "w2", "w3"},
            ubuntu = {"u1"},
            arch_linux = {"a1", "a2"}
        },
        pm = {
            windows = {"winget", "jdk.x.x"},
            ubuntu = {"apt", "jdk-tools"},
            arch_linux = {"pacman", "jdk-tools-2-g"}
        }
}

package = {
        name = "jdk-tools",
        version = "2.0.0",
        maintainer = "m-microsoft",
        deps = {
            ubuntu = {"w2", "w3", "w4"}
        },
        pm = {
            windows = {"winget", "jdk.x.x"},
            arch_linux = {"pacman", "jdk-tools-microsoft"}
        }
}

if 'deps/attr/maintainer' have diff between old version and new version. it may be hard to all-in-one.

[lvyuemeng]

many commands(install / config...) may be included for raw installation, so it is suppored by hooks function is better

I agree with this, we just need to abstract function as could as possble to reduce repetition.(raw as a pesudo package manager)

do you mean all versions into one file? It may be hard to implement or package structure will be complex.

my suggestion is actually you can't pack it all in one, if there's variations, and you need to keep it consistent, you can't avoid by packing it all in one.
we could try to develop a dynamic control for tables(based on isolated part like versions and vendors, if we could seperate it. And still keep the interface consistent. But I don't hope this would work due to diverse historical factors for every packages.).

I guess you misunderstand my suggestion. My real implementation is Package as a self-manager to control its Siblings, every Siblings is independent. My current thought is we could construct Generations to link versions for every Siblings, since versions need to be traced in certain circumstance.

[lvyuemeng]

Here is an example, previously, I identify version as a factor without discrepancy. Now I take it as a special factor:

local initKey(name, factors) -- factors to identify a independent sibling
  return package_name .. ":" .. table.concat(factors, ":")
end

local packages = {}

local function add(name, factors, version, configs)
  local key = initKey(name,factors)
  package[key][version] = { configs, parent = "..." } -- maintain a relation of versions
end