Alfred 3 (with input as argv): cannot import local Python modules [Fixed 3.0.2 b675]

[caleb531]

Hi,

 

I've been working to improve Alfred 3 support for one of the workflows I maintain (written in Python). For every one of my Script Filter and Run Script objects, I used to have the "with input as {query}" option selected. Since Alfred 3 introduced the ability to read input from argv (and recommends it), I was working today on updating my code to switch to reading via argv instead of via {query}.

 

However, when I change the selected option in my workflow objects and update my code to use sys.argv[1] instead of '{query}', my workflow-local Python modules (i.e. modules I place in the directory of the installed workflow) are now unable to be found.

 

I attached a simple example workflow which demonstrates the issue: open the workflow debugger and run the "dostuff" keyword in Alfred; you should notice in the logs that one script action passes, while the other fails.

Do Stuff.alfredworkflow

 

I'm using Alfred 3.0.1 build 671 on OS X El Capitan (10.11.5).

[deanishe]

Works for me…
 
 
 
Could you run this updated version that dumps sys.path, the current and script directories to the debugger?
 
Could someone else run it, too?
 
Because ARGV doesn't work as expected with various interpreters when you pass them a script rather than a filepath, Alfred has to write your script to a temporary file before running it to get things like $@ in bash and sys.argv in Python to behave normally.
 
This was something that I expected wouldn't work due to the import path, and I was surprised that it did. When I run the workflow, the workflow's directory (=CWD) is at the front of sys.path.

At any rate, it's simple enough to work around: use {query} or add CWD to your PYTHONPATH:

import os
import sys
 
sys.path.insert(0, os.getcwd())
 
import dostuff

Personally, I like to keep all the Python code in scripts and out of info.plist: 

# Language = /bin/bash
/usr/bin/python script.py "$@"

Edited June 2, 2016 by deanishe

[caleb531]

Alright, @deanishe, I've installed your updated version of the test workflow. Here's the debugger output after running it:

Starting debug for 'Do More Stuff'

[2016-06-02 11:44:24][utility.debug] Reading from query: passed

[2016-06-02 11:44:24][utility.debug] Reading from argv: failed

[2016-06-02 11:44:24][ERROR: action.script] /Users/Caleb/Library/Caches/com.runningwithcrayons.Alfred-3/Workflow Scripts
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC
/Library/Python/2.7/site-packages
CWD: /Users/Caleb/Dropbox/Applications/Alfred.alfredpreferences/workflows/user.workflow.3897A013-539B-4ECB-81C1-6107A9A2817A
SCRIPT DIR: /Users/Caleb/Library/Caches/com.runningwithcrayons.Alfred-3/Workflow Scripts

And yes, I realize there are solid workarounds. I already reverted my scripts to using {query} as they have been, though that doesn't always work for multiline input, which one of my workflow's action scripts must handle. Running Python from Bash as you suggested would fix that, and it seems like a much more elegant and reliable solution than {query}. Therefore, if all else fails with this issue, I'll probably resort to doing just that.

 

Still, I'm fascinated by the fact that you get different results than I, and so I'm still very much interested to see if you or anyone else finds additional insight into this issue.

Edited June 2, 2016 by caleb531

[deanishe]

Still, I'm fascinated by the fact that you get different results than I, and so I'm still very much interested to see if you or anyone else finds additional insight into this issue.

 

Yeah, me, too. Especially because I'm the guy that told Andrew that the ARGV method works perfectly with Python…

 

Now, it's starting to look like it doesn't in fact work. Here is what I get in the debugger:

/Users/daj/Library/Caches/com.runningwithcrayons.Alfred-3/Workflow Scripts
/Users/daj/Code/PythonLibs
/Users/daj/Dropbox/Config/Alfred 3/Alfred.alfredpreferences/workflows/user.workflow.736221EC-A6F2-48AC-827D-D1A4FFF4FFC8
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload
/Users/daj/Library/Python/2.7/lib/python/site-packages
/Users/daj/Library/Python/2.7/lib/python/site-packages/aeosa
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC
/Library/Python/2.7/site-packages
CWD: /Users/daj/Dropbox/Config/Alfred 3/Alfred.alfredpreferences/workflows/user.workflow.736221EC-A6F2-48AC-827D-D1A4FFF4FFC8
SCRIPT DIR: /Users/daj/Library/Caches/com.runningwithcrayons.Alfred-3/Workflow Scripts

 

As you can see, the working directory is near the front of my sys.path (after the script directory and my PYTHONPATH).

 

Could someone else run this workflow, so we can see who has the weird system here?

 

I have a growing dread it's me: As I said, I was surprised when imports worked during my tests, because I didn't think Python added the CWD to sys.path.

 

Should my system be the weird one, a fix in Alfred should be fairly straightforward (at least for Python scripts): Andrew would just have to add the workflow's directory to the PYTHONPATH environment variable.

 

As noted above, in the meantime, you can adjust sys.path yourself or use my preferred solution, which is to keep all your Python code in a script file and treat Alfred's Script box like a shell. Use it to call your script with the appropriate arguments, and nothing more.

 

That way, you can code in a proper editor with syntax highlighting and line numbers, and the Git repo is a lot easier to understand when all the code isn't embedded in info.plist.

Edited June 3, 2016 by deanishe

[Andrew]

Just a quick note, for the next release, when running Python scripts, I'm setting or appending the workflow folder to the PYTHONPATH environment variable.

 

Cheers,

Andrew

[deanishe]

Prepend, please. Appending the workflow's directory may not work as expected if PYTHONPATH isn't empty (the working directory should be before PYTHONPATH).

 

I'd recommend against overwriting it completely: that would cause the same import resolution problems for people who do have it set.

[Andrew]

Prepend, please. Appending the workflow's directory may not work as expected if PYTHONPATH isn't empty (the working directory should be before PYTHONPATH).

 

I'd recommend against overwriting it completely: that would cause the same import resolution problems for people who do have it set.

 

 

No probs, I've made that update for the next release - it also isn't overwriting if already set

[Andrew]

This is now in the 3.0.2 pre-release