问是否有可能创建一个具有特定Julia版本的虚拟env？

EN

默认行为是为major.minor版本创建一个公共共享命名环境。默认情况下，这通常是~/.julia/environments/1.7。

从Julia1.7开始，您可以创建一个共享命名环境，方法是以@作为项目名称的前缀，或者提供要激活的--shared选项。

(@v1.7) pkg> st
      Status `~/.julia/environments/v1.7/Project.toml`
  [295af30f] Revise v3.3.1

(@v1.7) pkg> activate @1.7.3
  Activating new project at `~/.julia/environments/1.7.3`

(@1.7.3) pkg> st
      Status `~/.julia/environments/1.7.3/Project.toml` (empty project)

(@1.7.3) pkg> activate --shared 1.7.3
      Status `~/.julia/environments/1.7.3/Project.toml` (empty project)

此外，您还可以随时将当前工作目录更改为另一个文件夹，并将其转换为一个环境。

请注意，环境堆栈。默认情况下，您的@1.7环境仍将为您的@1.7.3环境提供基础。您可以通过运行Base.load_path()来观察这一点。您可以通过操作LOAD_PATH创建不同的环境堆叠。

路径

您还可以使用环境变量来操作此操作。https://docs.julialang.org/en/v1/manual/environment-variables/

例如，这是在朱莉娅的conda锻造包中完成的。在这种情况下，整个朱莉娅仓库被转移到conda环境中。有关如何操作当前JULIA_PROJECT、JULIA_LOAD_PATH和JULIA_DEPOT_PATH的示例，请参阅下面。

https://github.com/conda-forge/julia-feedstock/blob/f9e44873689d69a87a5eaa544e7aaea6feebc50c/recipe/scripts/activate.sh#L12

朱莉娅环境不包含您想要运行它们的朱莉娅版本--写入Project.toml的版本界限只是对在环境中编写的代码的兼容性的限制，指定环境中的代码将使用的最低版本。您仍然需要安装适当的julia版本&在环境中使用它运行代码。

Project.toml和Manifest.toml只是为了给出一个可再现的环境状态，版本有界的依赖关系，朱莉娅本身就是其中之一。特别是，环境不包含其所有依赖项的代码和/或二进制工件。