使用CMAKE创建和激活Conda环境

发布于 2025-02-03 17:50:59 字数 933 浏览 2 评论 0原文

我在cmakelists.txt文件中有以下内容。我正在尝试使用cmake检查是否已安装在系统上并激活该环境的conda环境 。如果不存在环境,请创建环境并激活环境。这是假设Conda已经通过

# Create and activate a Python environment.

cmake_minimum_required(VERSION 3.18)

# Define the project
project(MyExample)

# Specify the C++ standard
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED True)

# Make sure Python is installed
find_package(Python REQUIRED)

# Activate conda environment, assume Anaconda or Miniconda is already installed
if(EXISTS /opt/miniconda3/envs/myenv)
    execute_process(COMMAND conda activate myenv)
else()
    execute_process(COMMAND conda create --yes --quiet --name myenv python)
    execute_process(COMMAND conda activate myenv)
endif()

当我运行上述cmake文件时,我会收到错误:

CommandNotFoundError: Your shell has not been properly configured to use 'conda activate'.

但是,我的系统上安装了conda,可以在终端中手动激活环境。为什么环境不会通过CMAKE激活?

I have the following in a CMakeLists.txt file. I'm trying to use cmake to check if a conda environment named myenv is installed on the system and activate that environment. If the environment does not exist, then create the environment and activate it. This assumes that conda is already installed via Anaconda (or Miniconda).

# Create and activate a Python environment.

cmake_minimum_required(VERSION 3.18)

# Define the project
project(MyExample)

# Specify the C++ standard
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED True)

# Make sure Python is installed
find_package(Python REQUIRED)

# Activate conda environment, assume Anaconda or Miniconda is already installed
if(EXISTS /opt/miniconda3/envs/myenv)
    execute_process(COMMAND conda activate myenv)
else()
    execute_process(COMMAND conda create --yes --quiet --name myenv python)
    execute_process(COMMAND conda activate myenv)
endif()

When I run the above cmake file, I get the error:

CommandNotFoundError: Your shell has not been properly configured to use 'conda activate'.

However, conda is installed on my system and I can activate the environment manually in the terminal. Why does the environment not get activated via cmake?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

苦行僧 2025-02-10 17:50:59

“为什么环境不会通过cmake激活?

第一个问题是错误消息中,这表明cmake评估execute_process_process命令的shell not知道什么conda激活的意思。

这可能是因为conda Init< shell>从未为Cmake使用的特定外壳(也许是?)运行。 此答案有一些详细信息conda Init做什么。这也可能是因为定义conda激活的Conda初始化代码仅在交互式外壳中加载 - 我不希望Cmake使用。 bash -l -c'conda激活foo')中执行执行

可能会有骇人听闻的方法来强制在交互式外壳( 这里的过程没有意义:CONDA环境的激活状态范围范围为外壳过程。我希望(sub)外壳在execute_process的完成后死亡。因此,即使激活起作用,它也不会在CMake脚本中持续存在。

一般而言

,此Cmake脚本似乎不是一个好方法。将代码的汇编与用户级别的特殊命名Conda环境的存在的紧密耦合似乎违背了CMAKE的精神,该精神旨在自动化软件依赖性的发现,以便用户不需要通常的硬编码位置。也许值得重新评估试图完成的事情和实现目标的策略。

例如,在Conda Forge上,许多软件包都用CMAKE编译,但是在那里的CMake是在已经激活的环境中执行的,并且本身对Conda一无所知。这使得CMAKE代码完全不可知其提供的依赖关系,我认为这是更清洁的工程。

"Why does the environment not get activated via cmake?"

The first issue is in the error message, which indicates that the shell that CMake evaluates the execute_process command under doesn't know what conda activate means.

This could be because conda init <shell> has never been run for the particular shell that CMake uses (bash, perhaps?). This answer has some details on what conda init does. It could also be because the Conda initialization code that defines conda activate only gets loaded in interactive shells - which I wouldn't expect CMake to be using. There might be hacky ways to force execution in an interactive shell (bash -l -c 'conda activate foo'), but that doesn't matter because...

Even if the above were working, the procedures here don't make sense: a Conda environment's activation status is scoped to the shell process. I would expect that the (sub)shell dies with the completion of the execute_process. So, even if the activation worked, it wouldn't persist any further in the CMake script.

Discussion

Generally, this CMake script does not seem like a good approach. Tight-coupling the compilation of code to the existence of a particularly-named Conda environment at the user level seems to go against the spirit of CMake, which aims to automate the discovery of software dependencies so that users don't need commonly hardcoded locations. Perhaps it might be worth reassessing what is trying to be accomplished and the strategy to get there.

For example, on Conda Forge, lots of packages compile with CMake, but there CMake is executed in the context of an already activated environment and itself knows nothing about Conda. This makes it so the CMake code is completely agnostic to how its dependencies are provided, which I regard as cleaner engineering.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文