每一个将Windows电脑作为主力机的用户, 如果有一定的编程需求, 都会问一个问题: 开发环境是直接在Windows中搭建呢, 还是全部在Linux子系统中搭建? 目前Windows的开发环境也不断进步, 不过Linux在众多涉及与大服务器对接的开发场景中仍是主流. 下面我试图列举将开发环境部署在WSL中的理由:
对于职业开发者来说, 或许Linux系统才是最好的选择. 因为WSL2确实有一些原生系统或者传统虚拟机所不具有的问题, 只能等待微软修bug–这听上去就不太靠谱. 网上大多关于Ubuntu的教程也必须小心使用, 不完全适用于WSL2. 这一篇文章中, 我将基于我的两次安装Ubuntu 22.04的经历, 介绍我在Windows11系统中的WSL2配置流程, 将避开我曾经踩的坑. 大多数不会给细节, 而是导向我参考的教程.
原则2: 软件更新日新月异, 参考的教程首选官方 QuickStart 和 Tutorial, 少用CSDN和各路中英文论坛.
安装 WSL Microsoft Learn: 下面我的示例发行版都是Ubuntu 22.04.2 LTS.
所有的新建文件夹、复制粘贴文件clash怎么本地不代理，、新建移动删除文件都可以用资源管理器进行. 比如可以在自己的用户文件名下面新建一个名为Projects的文件夹, 然后将你正在干的活 (写的latex项目, python代码等等)从Windows粘贴进去.
开始通过 WSL 使用 VS Code Microsoft Learn
首次运行该命令, 系统会指引你安装所需的包. 后面就可以顺利打开了, 右下角会有一个远程连接的绿色高亮字样, 应该需要安装一些remote插件.
的文件 VS code就会提示你安装对应拓展名的插件. 或者在插件商店中搜索你用的编程语言, 把(所有)下载量很高的都下载下来.
在Windows中下载好的插件, 是需要在WSL重新下载的. 最终插件页面会有两个分区,
wsl配置git环境_文艺圈不知名刘先生的博客-CSDN博客_wsl配置git： 可以参考其中关于ssh免密访问github的部分设置, 以后
. 当然, Git的命令实在太多了, 比如我要把Github上一个库的更新合并到我的本地, 就有
等等, 我没用过时也分不清楚 VS Code 中提供的那些个按钮是什么意思, 因此一开始用还是可以用命令行熟悉对应的命令(这方面教程很多), 然后再用更方便的可视化按钮.
重新安装某个WSL发行版: 见windows 11 重新安裝 wsl-Ubuntu22.04 完整過程 – HackMD.
下面进入WSL2中的一些具体环境配置. 首先需要注意到一个很重要的脚本文件, 即用户文件夹中的.bashrc. 这一脚本在每次开启WSL的时候都会先运行一遍, 我们经常会需要在这里添加环境变量啥的. 每次修改完.bashrc之后, 要用source ~/,bashrc或者重启terminal使其生效.
然后点击旁边的图标就会看到WSL的IP地址, 用这个地址代替常用的127.0.0.1就可以了. 设置代理可以以环境变量的方式进行, 可以直接写入到.bashrc文件之中, 就可以每次打开WSL都自动连接Clash代理了. 推荐几个教程:
第三个参考文章中定义了两个命令setp和unsetp, 分别用于在命令行中开启和关闭代理, 非常实用. 如果您是用Clash之外的其他代理软件, 可以参考第一个参考文章.
一些特殊的包, 遇到再下载就好了. 建议把base环境用作日常跑些小程序的Python环境, 当需要部署一些大模型的时候就新建虚拟环境.
寻找病因: 根据conda环境下pip install 无法安装到指定conda环境中, 在进入你的conda虚拟环境之后, 可以用命令python -m site来看这个环境会搜索包的路径是哪些, 不看不知道, 一看吓一跳, 里面的文件夹没有一个是我这个虚拟环境所在的目录!
正确操作配置好pip之后, 可以再次用python -m site检查一下, 可以看到sys.path都修正过来了, 但是USER_SITE 显示并不存在, 因为目录的版本号变为了正确的3.11. 无妨, 能运行就好.
安装好 VS code 中相关插件之后, Fortran 开发也可以全部在 VS code中完成. 只不过右上角的运行是最简单的单程序编译+运行; 复杂的编译链还是需要自己写 makefile文件, 比如先把各个.f90编译, 然后按理想顺序 link 起来, 最后得到一个文件来运行.
主要参照官方教程中的 Unix 部分, 所需用到的五个命令如下, 最后一个命令运行之后就开启了安装之旅, 需要较长的时间. 安装会自动选择最近的镜像站, 可以先把代理关掉.
更一劳永逸的是学会移植 Windows 系统的中文字体: 参考在Linux环境下安装texlive_卡拉潇克的博客-CSDN博客, 首先将Windows系统下的字体文件夹C:WindowsFonts整个拷贝到linux下的Home文件夹中 (只有个人文件夹有读写权限), 然后按下面命令操作
中文字体可以用fc-list :lang=zh-cn来查看在系统中的具体名字, 有了这个字体代号之后, LaTeX中调用中文字体可以见我另一篇文章Win10环境下LaTeX中文字体的设置 – 知乎 (zhihu.com).
后面想安装新的字体, 也可以将字体文件直接复制到对应位置, 然后按上面流程刷新一下字体缓存.
愉快完成LaTeX的配置之后, 开始编译tex文档, 才暴露出了wsl中一些我从来没有在 Windows 和 macOS 遇到的问题.
关于这个坑, 我花了很多时间才跳出来. 比如去网上找它对应的包和文件想着怎么塞进哪个文件夹去, 甚至用一些全局搜索工具来检索这个样式文件到底存不存在. 结果很惊人, 有些第三方库是包含在CTAN: Package newtx里面的, 明明在文件夹/usr/local/texmf-dist里面可以找到, 但却偏偏提示not found! 最后我看到Add/Find Style files in/to latex – Stack Overflow, 才找到了一个比较通用的解决方案.
安装好这个包之后, 再次对你的tex文件进行编译, 你很大概率又会发现有哪个sty文件又是 not found. 没关系, 不断重复上面的三个步骤即可. 直到你解决了所有的问题, 就可以顺利编译了. 给大家展示一下我编译我本科毕业论文时遇到的所有not found的样式文件:
最近在WSL中配置一些开源类GPT大模型, 经常会在CUDA方面遇到很多玄学问题让我痛不欲生 …… 但是 WSL 依然是我非常喜欢的一个Windows的功能, 与 Windows 文件打通 (访问Windows文件夹前面加一个mnt即可), 应用打通 (VS code, Clash); 同时又能互不干扰, 各自在编程开发和日常办公娱乐中发挥自己的长处. 长期使用图像化界面的Windows用户也能过一把命令行系统的瘾. 我对 WSL 的评价就是两个字: 优雅!
Windows 11 还有安卓子系统的功能. 集齐了 Windows, Linux 和安卓三个生态, 经历一波大换皮把macOS的许多设计都抄过来了, 如优化系统动画clash怎么本地不代理clash怎么本地不代理，、逐渐统一UI风格clash短视频、资源管理器的多标签页 (甚至Poweshell也有标签页了)…… 如此一盘大杂烩, 香!
