Python run script not finding installed modules

[Boofeast]

I <3 Alfred.

 

I have a workflow that uses a python (run) script. The script uses some modules that have been pip3 installed. Python3 has been installed via brew, which puts the executable in different places based on the architecture type (intel v. m1). I used to use the location of the exec in my script:

 

#!/usr/local/bin/python3

 

and changed to the following:

 

#/usr/bin/env python3

 

The script works great outside of my Alfred workflow but fails when invoked through Alfred with as ModuleNotFound error.  Any advice on what I am missing? THANKS!

 

 

[vitor]

Welcome @Boofeast,

Alfred doesn’t read your shell’s environment, so you’ll need to tell it where to find the language. Either by using the full path as you used to, or by populating your PATH before invoking the script.

Edited February 23, 2021 by vitor

[Boofeast]

Thanks @vitor. What is the Alfredian way to set my path, in a workflow that is running a python script (the script is on disk)?

 

[vitor]

Like you’d do it in an empty shell without startup files:

 

export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}"

/path/to/script.py

 

[deanishe]

1 hour ago, Boofeast said:

What is the Alfredian way to set my path, in a workflow that is running a python script (the script is on disk)?

 

Unless you really need to mess with PATH, it's usually better to just use the absolute path of the interpreter/script/whatever.

 

Changing the shebang back to #!/usr/local/bin/python3 is the proper solution, imo. The script doesn't work if you run it with any other Python, so it's a bit silly to write anything else in the shebang.

 

There’s no advantage to using #!/usr/bin/env python3 in a script that won’t run on any Python (i.e. no 3rd-party dependencies).

[vitor]

The practical reason to use env—as I understand it from the original post—is that if you have two Macs, one Intel and one ARM, both with Homebred-installed pythons, setting PATH will allow the Workflow to work on both machines when synced.

[deanishe]

Right, that is a massive PITA.

 

The best solution would be to make sure there’s a /usr/local/bin/python3 on every machine by symlinking, if possible. Or write your scripts to always work with the built-in Python (/usr/bin/python3), which is what I do.

 

/usr/bin/env makes script behaviour dependent on your environment, which is generally not desirable.

 

Apart from always having to mess with PATH if you want to run the script from anywhere but your shell (e.g. via Alfred or a Launch Agent), your script also won’t work if you’re in a virtual environment in your shell, because it will try to use the virtual environment’s Python instead.

 

Perhaps @Boofeast is smarter than me and won't have so much trouble with it, but I've caused myself a lot of confusion over the years using /usr/bin/env python as a shebang, and then having scripts misbehave or fail because they're not in a correctly-configured environment.

Edited February 24, 2021 by deanishe

[Boofeast]

Nope @deanishe I am not smarter than anyone. I have not had issues using /usr/bin/env because I usually only ever run my script in a small number of places with consistent configuration.

 

Thanks for all of the advice. I will probably just make sure that /usr/local/bin/python3 exists in all of the machines on which I run the workflow.