julia - 环境从默认环境继承包
问题描述
注意：这个问题是指 Julia v1.5。当然，在任何时候，理想情况下，答案也应该回答最新版本的问题。
Julia 安装提供了一个默认环境（例如，称为@v1.5）。在某个工作目录中运行 Julia 时，julia>] activate .可以创建一个新环境或激活当前环境（如果当前文件夹包含诸如 等文件Project.toml）。
当 Julia 代码在某个环境中运行时，该环境定义了可以通过using或导入哪些包（或模块） import。但是，始终可以使用安装在默认环境中的软件包。我没有在文档中看到这个事实（尽管它可能被提及）并且在花了一些时间追踪丢失的进口之后才学会了这个“艰难的方式”。
这有好处也有坏处：有时人们觉得需要使用不是项目真正一部分的包，例如，用于分析或调试。如果这些安装在默认环境中，则可以在不污染项目依赖项的情况下使用它们。另一方面，add尽管项目使用了包，但可能会忘记将某个包添加到项目的环境中。在这种情况下，其他用户无法从Project.toml和复制必要的环境Manifest.toml。（将重要的代码添加到在 Julia 启动时运行的 Julia 脚本中也会有这个缺点）。
在我看来，有几种方法可以解决这个问题：
- 随意使用从默认环境（和 Julia 启动时的脚本）继承的包，并让 CI 具有广泛的单元测试以实现可重复性
- 永远不要将包添加到默认环境中。注意不要在 Julia 启动时在脚本中导入包。
- 只需在项目/清单文件中包含您想要的所有包，无论实际存储库代码是否使用它们。
我的问题：是否有更多（更好的？）方法来处理这个问题？哪个选择对 Julia 来说是惯用的？
解决方案
LOAD_PATH负责确定构成有效环境的环境。默认情况下，它包括活动环境、默认环境和标准库。
Pkg.test测试，当由（或等效地）激活时，将pkg> test使用仅由被测试项目组成的无菌加载路径运行。因此测试只能访问由各自的Project.toml和Manifest.toml文件定义的依赖关系图。
在默认环境中包含实用程序（例如分析工具）似乎是标准做法。
如果你不喜欢这种行为，你可以LOAD_PATH在你的启动文件中修改为只包含活动项目。