0

I'm using setuptools for python packaging where I define console script entry points the usual way in the setup.py file:

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'
                                      ]},
     ...
)

After installing the package, I can call this entry point from a batch file like this:

my_CURRENT_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>

While this works, the use of the virtual environment is causing me to include all the path info before the entry point call, which in my view really destroys the simplicity an entry point is supposed to provide to the consumer of a script. Is there a way to get setuptools to register the entry point system-wide so that I can call the entry point without the path like this?:

my_DESIRED_batch_file.command

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

entry_point_name <my script args>

Without this complication introduced by the virtual environments, a console script entry point lets the script consumer use a script without having to know where the script is installed or even what language it's written in. I'd like to preserve this simplicity even when packaging in virtual environments.

What I've tried - I located the actual entry point file in the virtual environment after installing the package:

/anaconda3/envs/my_env/bin/my_entry_name

and placed a copy of this file in the main bin path:

/anaconda3/bin/my_entry_name

and found that I can then call the entry point without the path, as desired, however this is a manual step I don't want to make script consumers to do. Is there a way to get setuptools to place the entry point file in the general bin path rather than the environment bin or some other automatic means to this end?

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 (note: was moved from root to User/my_user/ by Catalina update)
  • Python: 3.7
  • Virtual env type: conda
cornas
  • 41
  • 1
  • 7

1 Answers1

0

Looks like conda run could help.

I can't test it, but looks like it could allow to write a much simpler shell script. Something like that:

#!/usr/bin/env sh

conda run -n ENV my_entry_name "$@"

Seems to be an experimental feature though.

sinoroc
  • 18,409
  • 2
  • 39
  • 70
  • It appears that function has been deprecated? Even if not, I don't think the call syntax is a gain in simplicity over full path to an entry point file. Still hoping to get back to the simplicity of just calling the entry point, period. Somehow... Thanks for the additional idea though! – cornas Oct 18 '19 at 21:10
  • I can't test it, but looks like it is not deprecated but still kind of experimental. The idea would be to write a one-liner in a shell script `conda run -n ENV entry_point_name "$@"`. – sinoroc Oct 18 '19 at 22:07
  • Good to know but still a lot less simple than `entry_point_name `. That's what I mean by make it available system-wide - function like an entry point functions when not using a virtual environment. I don't see much advantage of this over not using an entry point at all and just calling by `python path/to/script `. I'm trying to find a way to retain the full simplicity of the entry point. – cornas Oct 19 '19 at 23:07
  • In standard Python virtual environments it is a no-brainer. For conda/anaconda I can't help much further than giving you tips on how to write a shell script that would take advantage of `conda run`. You should rephrase your question and use the appropriate tags to get the attention of people who know conda. – sinoroc Oct 21 '19 at 09:32
  • Ok, so given that I didn't put conda in the question, how do you do this for a non-conda virtual environment? I'm not wedded to conda here - it's just what PyCharm made it easiest to do. – cornas Oct 22 '19 at 15:07
  • See my [answer to your previous question here](https://stackoverflow.com/a/58380170/11138259). Standard virtual environments don't have to be activated. The path to the right Python interpreter (the one in the virtual environment) is hard coded in the shebang. Just call the entry point and it should work just fine. Then it should be just a matter of making the virtual environment available, i.e. setting the right permissions just like for any other files and directories on your system. – sinoroc Oct 22 '19 at 15:41
  • Yes I’m aware of this part and it’s also true for conf a virtual envs. However, please reread this question. It’s not about activation but how to call just the entry point without a path to the entry point. That’s how an entry point normally works and should still work regardless of use of any kind of virtual env in my opinion. – cornas Oct 23 '19 at 16:17
  • OK, I might still be misunderstanding your request, but have you tried making the console script available via the `PATH` environment variable of your system? In case, here's an article about this topic, there are probably better ones but we have to start somewhere, hope it helps: https://cbednarski.com/articles/understanding-environment-variables-and-the-unix-path/ – sinoroc Oct 23 '19 at 18:11