gvcgo
一些建议，基于集中管理，快速搭建环境的角度
问题和一些思考：
问题1：vmr环境变量问题
应该有一个VMR_HOME（安装过程中选择的文件夹，默认.vmr）替换掉VMR_VERSION。VMR_HOME这个环境环境变量可以安装前配置，也可以安装后修改。
问题2：目前vmr对于不同sdk中的管理不够集中
描述：sdk会有需要进行二次管理“缓存”或“包”。例如bun有关于BUN_INSTALL 的环境变量，控制全局下载包和缓存；codna有envs和pkgs。（基于win的分盘，都会将这些设置到D盘，每次设置比较繁琐，故而有这个问题）
关于这点，scoop就可以比较和的解决，通过配置bucket的env_set和post_install。都可以将这些需要二次管理的资源一步管理，整理到persist文件夹。
所以也建议做些处理脚本或提示信息等功能，方便进行配置。比如整理到 VMR_HOME\blocks
问题3：迁移问题
描述：一些场景比如重装系统，新机迁移等，需要进行重新配置环境的情况。没有看到vmr的解决方案。
例如导入导出的功能。实现这样的功能：在新机上下载好vmr，只需要拷贝VMR_HOME文件夹，然后导入配置。
问题4：sdk环境变量问题
每个sdk的环境变量做的太分散了，相当于每有一个新sdk，就要在path新添一行。这样环境变量变得很臃肿，不是很清爽，后续如果有情况需要处理的时候较为麻烦。（感觉和用一个vmr管理所有sdk的理念并不符合）
可以尝试有一个 VMR_HOME\bin 来统筹管理
问题1： vmr只是自身安装目录固定为$HOME/.vmr。windows下面可以自行把.vmr隐藏。另外，vmr安装过程可以指定SDK存放目录，与.vmr安装目录分开，这样避免windows下C盘不够大的问题。所以，定不定制vmr安装目录，影响不大。
问题2： 关于SDK的某些环境变量，用于控制SDK安装路径、SDK管理的package的安装路径等等，例如rust、node.js、conda之类的。可以先自行手动设置。后面发行的大版本会以lua插件的形式支持SDK，用户可以贡献自己的插件。
问题3： 这个挺好，可以考虑有一键迁移的功能。
问题4： 统一到$VMR_HOME/bin需要创建必要的可执行文件以及依赖库的快捷方式到相应的目录，SDK多了之后只会更乱更麻烦。后面的Windows环境变量，考虑采用注册表的方式，在Path里面就会比较清爽了。
问题1： vmr只是自身安装目录固定为$HOME/.vmr。windows下面可以自行把.vmr隐藏。另外，vmr安装过程可以指定SDK存放目录，与.vmr安装目录分开，这样避免windows下C盘不够大的问题。所以，定不定制vmr安装目录，影响不大。
问题2： 关于SDK的某些环境变量，用于控制SDK安装路径、SDK管理的package的安装路径等等，例如rust、node.js、conda之类的。可以先自行手动设置。后面发行的大版本会以lua插件的形式支持SDK，用户可以贡献自己的插件。
问题3： 这个挺好，可以考虑有一键迁移的功能。
问题4： 统一到$VMR_HOME/bin需要创建必要的可执行文件以及依赖库的快捷方式到相应的目录，SDK多了之后只会更乱更麻烦。后面的Windows环境变量，考虑采用注册表的方式，在Path里面就会比较清爽了。
注册表方式才是最糟糕的！
