新建conda环境和换backbone的原则

我以前只要找到一个项目就把相关的环境装在一个新的conda环境里，pytorch和cuda匹配这些问题其实重复解决过很多次，但是因为每次都从头开始解决，所以就好像每次都卡在这或者把时间又花在上面：如果源莫名出问题了，再用pip config设置源；如果需要的包没有，再去pypi或者什么收藏的下载torch和cuda的网站上去下载whl到本地，chmod ...再安装，一堆操作；

特别是我之前折腾了一个环境好久没成，在咸鱼上找人帮忙，开始要35，后来要400，我真的是无语了，又找了另一家说晚上看看，再没声音了；

这次，我先查找本地已有的环境，里面有一个RIPU的是我之前折腾了好久但是效果不好的项目，项目虽然没坚持下去，但是环境还能用呀，于是，就在这个环境的基础上，我又根据报错小修小补地装了些包，然后就能用了，当然，mmcv还是报错了，说版本不行，我想着保留原来的，然后就用pip install mmcv==1.6.2 --force-reinstall 相当于重命名了，而且这个重装的过程其实pip自己也在复制，把原本的包从/home/usr/.local/lib/python3.7/site-packages/下复制到新的环境下的，话说很奇怪，我RIPU这个环境明明是放在/home/miniconda/envs/RIPU/lib/python3.7/site-packages/下的，但是有一些却在.local下，就感觉很怪；然后根据报错要求的mmcv版本和cuda  torch那些根据下面这个文档里的规则匹配
Installation — mmcv 2.2.0 文档

根据生成的代码安装了新版的mmcv；至此环境的问题基本解决了；

小结：新装环境或者新记录一个什么内容之前，先看看自己之前有没有做过类似的工作，大概率是有的对于喜欢从头开始的人来说，那么找到之后就在这个基础上改改，然后发现，很快的；

很多自己遇到的问题在我的宝藏学长那里都不是问题，他说环境的路径就配过一次，安装包啥的，也都是确定迁移以后，从原来环境的相应位置复制到现在环境的相应位置，其实就是这样，解决起问题还是很快的；

由于使用了mmdet  mmengine  mmcv这类框架，在导入的时候还是有很多问题，有些网上一搜好解决，有的是项目自己写的一些相对导入的，比如from ..builder import BACKBONES找了半天都在说相对导入的问题，但我的问题是我的目录下压根就没有这个builder文件，后来还是依照上述原则，找到了之前一个项目，里面结构和这个新项目差不多，我就把用到的部分复制了过来；

我以前之所以每次都从头开始，其实就是没有一种把问题简化的意识，最近参考了学长的github仓库，他把项目就拆得很简单，因为每次换项目都要重新适应数据预处理，训练过程那些，不同项目写得五花八门的，最近我终于定在了UCT的这个训练过程上，有早停啥的，文件管理得都很清楚，所以拆解项目这些的好处就在于你可以各取所长，有的项目的训练过程比较完备好管理，就拿来用用，通常其实只需要换网络就ok了，所以如果没有这样简化问题了话，可能每次都要从安装环境开始，但是这样一化简，就可以从已有的很多基础上开始了，这一点非常必要，一方面是节省时间，比较那些环境，训练过程啥的，如果不是你的研究重点的话，就是应该当作常量来考虑的；另一方面，这就是学习的必要性了，有些人没有读过书，可能自创了一套解释问题的说法，别人听着是一通经验，因为可能没读过书不会用术语去说这些问题，而如果读过书了，其实就没必要再自己去建构这些已经成为惯例的东西了，但是其实很多时候，初学者没有学习意识，比如没有上网查教程，b站视频或者各种内容的习惯的话，其实很容易陷入这种自己创一套，然后还很蹩脚不成体系，最后发现其实已经存在了的东西，其实科研应该避免这类时间的开销的，你不用从头开始构建一个元宇宙，就像有个书就叫：如果从头开始做一个苹果派，你可以创造一个宇宙，是的，就是这么大的工作量，而且你做的所能被看见的部分得是和人类文明发展到今天以及之后的部分重叠了才能被看到，不过开个玩笑，事实上这种情况也不可能真那么初级，起码我们不会从头去写操作系统，当然确实有的课要求这么写过；

说到这，我还是要说一说研究生和学长等前辈交流的必要性的，其实博士们的建议，就算你初学者再怎样也是要听的，毕竟是初学者，来上学还是要尽量和周围的学长同学啥的交流的，各方面都ok，网络上的东西再丰富，还是不能代替现实世界的情况，毕竟每个人看问题的角度关注的点都不一样，所以永远地珍惜当下吧，越长大越发现，每个人都只是陪自己一段，拥有的时候，珍惜吧。