曾几何时, 在我的开发机器之上, nvm、pyenv、rbenv得以同时被安装, 还有一个需手动管理的Go它们就这样存在着。每个语言, 都配备有与之对应的一个版本管理器, 然而, 每个版本管理器的命令却是不尽相同的。只要切换任何一个项目, 首先就得执行nvm use这个操作, 紧接着还要进行pyenv local相关操作, 对于Go而言也得做出相应更改。光是环境管理这一项工作, 就足以让人焦头烂额。更让人烦躁的是, 新同事加入了。一个项目 需要某个版本, 就是 Node版本要 , 版本是 3.11 , 还有特定版本的某个工具链, 他得逐个去安装管理器, 还要挨个切换版本, 结果折腾了半天, 还是配置不正确。“在我机器上这个可是没问题的”, 这话, 麻烦的原因有一半就在这儿。之后, 我更换了, 那个以前称作 rtx 的 mise, 这一堆东西, 全都丢弃了, 有一个工具, 能够搞定, 所有语言的版本管理。它到底替代了什么概括来讲, 在这一范畴之内的所有事物, mise大体上均能够予以替代, 它的后端与有着诸多种类插件的asdf生态相互配套兼容, 以至于能够安装的各类物品相当丰富。你以前用的mise 里怎么管nvm / fnmmise use node20pyenvmise use 3.12rbenvmise use ruby3.3手动管的 Gomise use go1.23一堆 CLI 工具版本mise use 1.9、mise use jq一套命令所有语言通用。不用再记每个管理器各自的黑话。核心是一个 mise.tomlmise 让我最为满意之处在于, 版本配置是依照项目来进行的, 它被写在位于项目根目录的一个文件当中 , 无论谁将其 clone 下来 , 进入对应目录 , 版本便会自动处于正确状态。# mise.toml放在项目根目录提交进 gitnode 20.11.0 3.12go 1.23# 工具也能管团队用同一个版本免得各装各的 1.9.5“npm:pnpm”等于“9”, 还存在能够直接安装npm全局包, 且对版本进行锁定的情况。# 进这个目录自动设环境变量相当于内置了 :///tasks.dev# 顺手还能定义任务省得到处找run pnpm devtasks.testrun pnpm test把这个文件提交进 git新同事的入职流程就变成了# 装 misemac/linux 一行搞定curl | sh# clone 项目进目录git clone cd myapp通过执行一条命令, 将mise。toml文件里, 涉及的全部语言以及其对应的工具版本, 都完整无误地安装好。mise进到目录之际, 版本以及环境变量会自动进行切换, 此操作需要在 shell 里面对 mise 进行一下 hook 哦。mise dev # 直接跑上面定义的 dev 任务现在, 这一回, Node、Go以及pnpm, 均按照文件当中所书写的版本完整安装齐全。以往需要耗费半天时间的环境配置, 当前仅需一条命令, 借助几分钟即可完成。这正是我更换它的最为主要的动力所在。它比 asdf 强在哪或许会有人讲, 难道 asdf 不是如此这般吗? 我曾使用过 asdf, mise 在某些要点方面的确更加便利顺手:其一, 速度快。mise 是由 Rust 编写而成, asdf 属于 shell 脚本, 在切换目录时, 针对钩子开销方面, mise 几乎难以察觉有影响, 然而 asdf 在某些机器上会存在明显卡顿, 需要注意才行。第二, 并非每个语言都需先行安装。对于asdf, 唯有先作asdf add才能安装node, 而mise针对常见语言已将后端内置, 如此, 直接使用mise use node20即可, 步骤较之于前者少一步。第三, 其内部设置了env管理以及task。上面提及的那个和, 就如同将和一个轻量级的make一同收纳了进来。我当下在项目里基本上不再单独使用.envrc以及了。几个要注意的点要配置 shell 集成, mise 的版本自动切换, 是靠在你 shell 启动时进行 hook也就是往 .zshrc / . 里添加一行 eval$(mise zsh) 来实现的, 不配这个自动切换就不会生效, 就得手动执行 mise use, 这是新手最容易忘记的一步。老式的, 那个.nvmrc文件, 还有那个带点的杠开头的文件, mise也是能够识别的, 在进行迁移操作的时候呀, 并不需要马上就把它们全部删除掉, mise是可以读取这些文件的, 如此也就能够一步步地循序渐进朝着mise.toml进行迁移了。另外, 对于团队推广而言, 需要做到统一。此工具的价值体现于全员运用同一套, 要是存在有人使用mise, 而有人依旧抱着nvm的情况, 那么「clone下来环境就能保持一致」所具备的好处便会大打折扣。我们小组采取的方式是召开一次简短的会议, 演示一番直至运行起来有多迅速, 如此一来大家就都进行更换了——毕竟没有人会乐意去配置环境。现在, 我的开发机干干净净的, 仅有一个 mise 在上面。想要换项目, 还得带新人, 让新人上手, 并且在 CI 里重新营造那个环境, 从头到尾用的都是同一个 mise.toml 。那种先前每个语言都有一个管理器, 而且各语言运行的命令都不一样的往日时光咩, 已经没办法回去并且想回, 也不想回罗。
Python reload？不如先扔掉你那一堆烦人的版本管理器
曾几何时, 在我的开发机器之上, nvm、pyenv、rbenv得以同时被安装, 还有一个需手动管理的Go它们就这样存在着。每个语言, 都配备有与之对应的一个版本管理器, 然而, 每个版本管理器的命令却是不尽相同的。只要切换任何一个项目, 首先就得执行nvm use这个操作, 紧接着还要进行pyenv local相关操作, 对于Go而言也得做出相应更改。光是环境管理这一项工作, 就足以让人焦头烂额。更让人烦躁的是, 新同事加入了。一个项目 需要某个版本, 就是 Node版本要 , 版本是 3.11 , 还有特定版本的某个工具链, 他得逐个去安装管理器, 还要挨个切换版本, 结果折腾了半天, 还是配置不正确。“在我机器上这个可是没问题的”, 这话, 麻烦的原因有一半就在这儿。之后, 我更换了, 那个以前称作 rtx 的 mise, 这一堆东西, 全都丢弃了, 有一个工具, 能够搞定, 所有语言的版本管理。它到底替代了什么概括来讲, 在这一范畴之内的所有事物, mise大体上均能够予以替代, 它的后端与有着诸多种类插件的asdf生态相互配套兼容, 以至于能够安装的各类物品相当丰富。你以前用的mise 里怎么管nvm / fnmmise use node20pyenvmise use 3.12rbenvmise use ruby3.3手动管的 Gomise use go1.23一堆 CLI 工具版本mise use 1.9、mise use jq一套命令所有语言通用。不用再记每个管理器各自的黑话。核心是一个 mise.tomlmise 让我最为满意之处在于, 版本配置是依照项目来进行的, 它被写在位于项目根目录的一个文件当中 , 无论谁将其 clone 下来 , 进入对应目录 , 版本便会自动处于正确状态。# mise.toml放在项目根目录提交进 gitnode 20.11.0 3.12go 1.23# 工具也能管团队用同一个版本免得各装各的 1.9.5“npm:pnpm”等于“9”, 还存在能够直接安装npm全局包, 且对版本进行锁定的情况。# 进这个目录自动设环境变量相当于内置了 :///tasks.dev# 顺手还能定义任务省得到处找run pnpm devtasks.testrun pnpm test把这个文件提交进 git新同事的入职流程就变成了# 装 misemac/linux 一行搞定curl | sh# clone 项目进目录git clone cd myapp通过执行一条命令, 将mise。toml文件里, 涉及的全部语言以及其对应的工具版本, 都完整无误地安装好。mise进到目录之际, 版本以及环境变量会自动进行切换, 此操作需要在 shell 里面对 mise 进行一下 hook 哦。mise dev # 直接跑上面定义的 dev 任务现在, 这一回, Node、Go以及pnpm, 均按照文件当中所书写的版本完整安装齐全。以往需要耗费半天时间的环境配置, 当前仅需一条命令, 借助几分钟即可完成。这正是我更换它的最为主要的动力所在。它比 asdf 强在哪或许会有人讲, 难道 asdf 不是如此这般吗? 我曾使用过 asdf, mise 在某些要点方面的确更加便利顺手:其一, 速度快。mise 是由 Rust 编写而成, asdf 属于 shell 脚本, 在切换目录时, 针对钩子开销方面, mise 几乎难以察觉有影响, 然而 asdf 在某些机器上会存在明显卡顿, 需要注意才行。第二, 并非每个语言都需先行安装。对于asdf, 唯有先作asdf add才能安装node, 而mise针对常见语言已将后端内置, 如此, 直接使用mise use node20即可, 步骤较之于前者少一步。第三, 其内部设置了env管理以及task。上面提及的那个和, 就如同将和一个轻量级的make一同收纳了进来。我当下在项目里基本上不再单独使用.envrc以及了。几个要注意的点要配置 shell 集成, mise 的版本自动切换, 是靠在你 shell 启动时进行 hook也就是往 .zshrc / . 里添加一行 eval$(mise zsh) 来实现的, 不配这个自动切换就不会生效, 就得手动执行 mise use, 这是新手最容易忘记的一步。老式的, 那个.nvmrc文件, 还有那个带点的杠开头的文件, mise也是能够识别的, 在进行迁移操作的时候呀, 并不需要马上就把它们全部删除掉, mise是可以读取这些文件的, 如此也就能够一步步地循序渐进朝着mise.toml进行迁移了。另外, 对于团队推广而言, 需要做到统一。此工具的价值体现于全员运用同一套, 要是存在有人使用mise, 而有人依旧抱着nvm的情况, 那么「clone下来环境就能保持一致」所具备的好处便会大打折扣。我们小组采取的方式是召开一次简短的会议, 演示一番直至运行起来有多迅速, 如此一来大家就都进行更换了——毕竟没有人会乐意去配置环境。现在, 我的开发机干干净净的, 仅有一个 mise 在上面。想要换项目, 还得带新人, 让新人上手, 并且在 CI 里重新营造那个环境, 从头到尾用的都是同一个 mise.toml 。那种先前每个语言都有一个管理器, 而且各语言运行的命令都不一样的往日时光咩, 已经没办法回去并且想回, 也不想回罗。