站在用户角度看LLAR

[MeteorsLiu]

我一直在思考，LLAR最好的交互方式是什么

一开始的想法：
只给出LinkFlags和CompileFlags，因为LLGo和LLPkg只需要这些东西

但周五吃完饭后，我准备写一篇文章介绍LLAR的时候，在思考与其他包管理器不同的地方。我忽然发现，我的想法，是只考虑了LLGo。

而没有从用户角度出发了解用户到底需要怎样的包管理器，于是深夜写了这个文章。

我们重新思考，用户到底需要什么包管理器？

[MeteorsLiu]

1. 构建编译类

Conan，Xmake之类包管理器就是典型编译类包管理器，其输入是一个依赖库，输出是Cmake或者别的编译工具的构建说明文件

2. 系统管理类

Homebrew，NixOS，Apt，都是典型的系统管理类包管理器，其目的都是帮助用户安装某个依赖到系统上，所以它不会生成任何构建说明文件，也不会将安装的库进行隔离。而是将库安装到统一系统路径下，让其他人能够找到

3. 构建工具组件类

LLAR一开始就是这样一个角色，它可能只是LLGo这类构建工具一个组件，而不是一个完整的包管理器。因为它只有最纯粹的编译类输出，而与构建编译类不同，构建编译类是用户选择构建工具，然后生成。构建工具组件则是相反，是这个组件决定了用户只能选择什么构建工具。
这类包管理器不仅仅是只有LLAR，Npm，Cargo，Go Module都是此类包管理工具。他们并不能称之为包管理器，因为他们只允许用户选择有限语言。

[MeteorsLiu]

上述三种模式，其实代表三种设计哲学。

1. 用户需要什么，我就给你什么
2. 用户需要什么，我不知道，但是我会把物品放在公共地方，他需要什么就拿什么
3. 我不在乎用户需要什么，我就给你这些，用户只能用我给的

[MeteorsLiu]

从LLAR设计角度出发，其实LLAR应该要和Conan保持一致：用户需要什么，我就给什么。然而，这种设计模式，我其实是保持疑问的。

1. Conan只专注于C/C++，LLAR并不局限于某种语言，这意味着我们需要花大量时间去解决用户需求问题。

可是包管理器不应该是用户需要什么就拿什么么？而不是满足用户一切的需求。

这二者逻辑是这样的：
用户需要什么拿什么：我给你这个库所有构建参数，你需要你自取，其实.pc文件本质上就是这么一个东西

而Conan这是将这个问题变成了：用户现在需要Cmake，所以我要生成一个Cmakefiles出来给用户

[MeteorsLiu]

所以我想，我们应该还是要做：用户需要什么就自己拿什么，但是要让他拿得方便，拿得轻松

[MeteorsLiu]

2. 既然如此，这已经演变成了系统包管理器了，就是拿得简单就是放在一个操作系统公认的地方

但是这对吗？这不对。为什么不对。
这其实将用户操作系统与用户编译环境捆绑，变成了一对一的关系

但很多情况下，操作系统与用户编译环境往往是一对多，用户电脑上有无数的库，但只有一个操作系统

[MeteorsLiu]

3. 而特定语言，特定范围，不应该是LLAR要做成的东西

[MeteorsLiu]

所以，我们需要的应该是：

1. 方便用户轻松拿，甚至不需要额外做配置就能使用，轻松切换库的东西
2. 必须是多个库兼容的，互相隔离，不能放在一个地方

[MeteorsLiu]

所以，llar安装，不应该输出任何东西。
而是提供一种方式，可以通过llar切换库，使其被用户轻松使用，不需要任何额外手段获取，而且必须要严格隔离。

[MeteorsLiu]

可是这种切换机制，却不适合LLGo这种自带版本管理系统的东西

[MeteorsLiu]

我想到一个好主意，可以切换pc来实现兼容LLGo逻辑

[MeteorsLiu]

经过几天思考和观察：

我想可以回答这个问题：用户需要什么的包管理器？

1. 构建类（什么是构建类包管理器，一般构建类包管理器就是辅助构建系统构建的，当然也有像Xmake这种构建系统与包管理器结合的）
2. 全局类（LLGo，LLPkg）

根据以上构建目的的不同，大致可以可以分为两种模式：

1. 构建类往往需要自己手写配方，用于构建自己的项目
2. 全局类不需要手写配方，只需要用已经写好的配方就行

其实无非就是在LLAR基础上再新增一个构建用户自己配方需求，其实这是好实现的

[MeteorsLiu]

所以，llar安装，不应该输出任何东西。 而是提供一种方式，可以通过llar切换库，使其被用户轻松使用，不需要任何额外手段获取，而且必须要严格隔离。

根据本issue讨论的设计出发点：

MVP计划新增以下接口：

// Use configures the build environment to use the specified module.
func (p *ModuleF) Use(mod module.Version, matrix Matrix)

Use其实就是“切换”的思想，它通过修改环境变量实现了动态切换用户需要的库

Example:

	for dep in proj.Deps {
		use dep, proj.Matrix
		echo "use ${dep.ID} ${dep.Version}"
	}

然而llar在系统层面上，无法实现“切换”。因为我们不能假设用户电脑上只有一个包管理器。

对于系统层面，我们会给出其“编译参数”，或者根据不同语言构建标准给出对应参数。

例如C/C++就给出pkg-config结果