当安装的软件包使用conda虚拟环境时，如何使Python控制台脚本入口点起作用? [英] How do you make Python console script entry points work when installed package uses a conda virtual environment?

问题描述

问题- 从非虚拟环境转换到conda虚拟环境会导致无法识别控制台脚本入口点.

背景- 最近，我试图让人们相信在我的Python项目中使用虚拟环境.我决定在更新macOS Catalina之后导致所有PyCharm项目显示无效的解释器错误，然后执行此操作.我以为将一个大混乱扔在另一个之上可能会出什么问题?"两天后，我终于可以再次运行脚本了-我遇到过的最糟糕的砖墙.我在任何地方都找不到解决方案，所以我写了我的第一个SO问题和后续的解决方案，以为我可能终于可以对我使用了这么长时间的网站有所帮助. >

我的设置

• 操作系统:macOS Catalina
• Shell:bash(是的，我在Catalina更新后将其改回了，并取消了烦人的"zsh现在是默认值"消息)
• IDE:PyCharm 19.1 Pro
• Anaconda:4.4.7
• Python:3.7

上下文- 我开发了几个交互的数据科学软件包，并通过以下方式将它们本地安装为可编辑模式:

My_Machine:my_package my_user_name$ pip install -e .

我使用带有setuptools的setup.py文件创建python软件包，并使用PyCharm进行构建.在setup.py文件中，我定义了控制台脚本入口点，如下所示:

setup.py :

# -*- coding: utf-8 -*-

from setuptools import setup, find_packages

setup(...
      name='my_project',
      entry_points={'console_scripts':['my_entry_name=my_package.scripts.my_python_script:main'
                                      ]},
     ...
)

在转移到conda虚拟环境之前，我已经通过这样的批处理文件运行了好几年的脚本:

my_batch_file.command:

#!/bin/bash
cd "$(dirname "$0")"  # set the working directory as the command file locations

my_entry_name <script arguments>

但是，在转移到conda虚拟环境之后，运行命令文件会产生my_entry_name: command not found错误.

到目前为止已经尝试过

• 已验证并尝试通过which python终端命令设置使用哪个python.我可以看到默认值为/Users/my_user_name/anaconda3/bin/python，如果我从项目中的命令提示符处执行此操作，则会看到/Users/my_user_name/anaconda3/envs/my_env/bin/python，反映了预期的环境版本.
• 检入/Users/my_user_name/anaconda3/envs/my_env/bin/my_entry_name中的实际入口点文件以查看shebang行如何指示python版本，即#!/Users/my_user_name/anaconda3/envs/my_env/bin/python
• 试图将这个shebang添加到我的.command文件的顶部
• 多次重新安装我的软件包，以为入口点可能无法正确注册.
• 对bash与zsh的了解很多，认为Catalina更新到zsh的过渡，再回到bash可能会引起问题.
• 试图从虚拟环境中恢复到正常运行状态，但无法使PyCharm非虚拟解释器设置再次起作用.
• 查看了$ PATH内容以查找问题.
• 阅读许多有关虚拟环境的教程(我发现所有内容都只是从最基础的角度出发)
• 关注与虚拟环境相关的setuptool中的错误的线程
• 这些努力的许多组合.

均不起作用-相同的my_entry_name: command not found错误.令人沮丧的两天.

解决方案

经过进一步的输入和试验后修订的答案.我发现了两个选项，两个选项都需要知道定义入口点的实际文件在哪里.对于conda虚拟环境，将在这里:

/anaconda3/envs/my_env_name/bin/entry_point_name

如果调用此文件，则无需指定python版本或激活环境.我发现了两种方法可以做到这一点:

选项1 -感谢@sinoroc，他首先指出，如果正确调用了入口点，则无需激活虚拟环境.对于conda虚拟环境，应为:

my_batch_file.command

#!/bin/bash
cd "$(dirname "$0")"  # set the working directory as the command file locations

~/anaconda3/envs/my_env_name/bin/entry_point_name <my script args>

对于其他类型的虚拟环境，您只需调整路径详细信息即可进入入口点文件.

选项2 -如果将入口点文件的副本放置在主要的Anaconda箱中:

/anaconda3/bin/my_entry_name

您无需指定路径，就可以像调用它们一样调用入口点，恕我直言-即使脚本用户不受语言影响并安装详细信息:

my_batch_file.command

#!/bin/bash
cd "$(dirname "$0")"  # set the working directory as the command file locations

entry_point_name <my script args>

由于此手动复制步骤并不理想，因此我发布了一个有关如何更好地做到这一点的问题:

My setup

• OS: macOS Catalina
• Shell: bash (yes, I changed it back after Catalina update and suppressed the nagging 'zsh is now default' message)
• IDE: PyCharm 19.1 Pro
• Anaconda: 4.4.7
• Python: 3.7

Context - I develop several interacting data science packages and locally install these in editable mode as a general practice via:

My_Machine:my_package my_user_name$ pip install -e .

I create python packages using a setup.py file with setuptools, building using PyCharm. Within the setup.py file, I define console script entry points like this:

setup.py:

# -*- coding: utf-8 -*-

from setuptools import setup, find_packages

setup(...
      name='my_project',
      entry_points={'console_scripts':['my_entry_name=my_package.scripts.my_python_script:main'
                                      ]},
     ...
)

Before shifting to a conda virtual environment, I was running script perfectly fine for years via a batch file like this:

my_batch_file.command:

#!/bin/bash
cd "$(dirname "$0")"  # set the working directory as the command file locations

my_entry_name <script arguments>

However, after shifting to a conda virtual environment, running the command file produces a my_entry_name: command not found error.

Things tried so far

• Verified and tried to set which python is used via which python terminal command. I can see that the default is /Users/my_user_name/anaconda3/bin/python and if I do this from the command prompt within my project, I see /Users/my_user_name/anaconda3/envs/my_env/bin/python, reflecting the environment version as expected.
• Checked in the actual entry point file in /Users/my_user_name/anaconda3/envs/my_env/bin/my_entry_name to see how the shebang line indicates the python version, which was #!/Users/my_user_name/anaconda3/envs/my_env/bin/python
• Tried adding this shebang to the top of my .command file
• Reinstalled my package many times, thinking the entry point might not be registered right somehow.
• Messed around with bash vs. zsh a lot, thinking the transition to zsh by Catalina update, and back to bash might have caused problems.
• Tried to get back to functioning by going back from virtual environment, but couldn't get PyCharm non-virtual interpreter settings to work again.
• Looked at $PATH contents for issues.
• Read lots of tutorials about virtual environments (all I found stop at very basics)
• pursued threads about bugs in setuptools related to virtual environments
• Many combinations of these efforts.

None of this worked - same my_entry_name: command not found error. Extremely frustrating two days.

解决方案

Revised answer after further input and experimenting. I've found two options where both require knowing where the actual file is that defines the entry point. For a conda virtual environment, it will be here:

/anaconda3/envs/my_env_name/bin/entry_point_name

There is no need to specify the python version or to activate the environment if this file is called. I've found two ways to do this:

Option 1 - Credit to @sinoroc who first pointed out the virtual environment does not need to be activated if the entry point is called correctly. For a conda virtual environment, that would be:

my_batch_file.command

#!/bin/bash
cd "$(dirname "$0")"  # set the working directory as the command file locations

~/anaconda3/envs/my_env_name/bin/entry_point_name <my script args>

For other types of virtual environments, you would just adjust the path details to get to the entry point file.

Option 2 - If you place a copy of the entry point file in the main Anaconda bin:

/anaconda3/bin/my_entry_name

you don't need to specify the path, letting you call the entry point like they should work, imho - ie shields the script user from language and install details:

my_batch_file.command

#!/bin/bash
cd "$(dirname "$0")"  # set the working directory as the command file locations

entry_point_name <my script args>

As this manual copy step is not elegant, I have posted a question about how to do this better: How do you make an entry point to a script in a virtual environment available system-wide?

这篇关于当安装的软件包使用conda虚拟环境时，如何使Python控制台脚本入口点起作用?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！