solved Is it possible to use a Python script with Text View?

[csjaugustus]

Hi there! I am trying to make an interactive Text View, sort of like the ChatGPT/Dall-E workflow, except I'm trying to use a Python script instead of JS. 

 

I've tried setting in the Text View configuration Source > Script: python_script.py (it can open normally when I click open), but it always throws a permissions error (as attached). 

 

I've tried reading the docs on Text View and it doesn't say I can't use Python. It merely says that the output of the script has to be in the specified JSON format. And I've used Python for Script Filter objects before, outputting in the required JSON format, and having it work perfectly. I'm just not sure what I'm getting wrong with Text View and there isn't a lot of sample workflows at the moment. Any ideas how I could achieve it? Does Text View accept Python scripts, and if so what might I be doing wrongly?

 

Additional info regarding the script:

It's a really simple ask and answer script. You can think of it as something like: Guess a number > User guesses a number > if correct say correct, else keep reprompting. It's not important for now since I'm just trying to figure out the basics of the Text View object. 

 

Any help would be greatly appreciated. Please do let me know if you need more info. Thanks in advance!

Edited April 8 by csjaugustus

[vitor]

Welcome @csjaugustus,

 

Yes, you can use literally any language, just like the Script Filter. All your stated assumptions are correct, but note the message (emphasis added): The external script may not exist, or doesn't have execute (+x) permissions. What you have to do is locate your script inside the workflow’s folder and (with a terminal) do chmod +x /PATH/TO/SCRIPT/HERE, which will make it executable.

When you create the script directly from Alfred by setting the Text View source to Script, typing a name, and pressing Create, that is automatically done for you.

[csjaugustus]

11 minutes ago, vitor said:

Welcome @csjaugustus,

 

Yes, you can use literally any language, just like the Script Filter. All your stated assumptions are correct, but note the message (emphasis added): The external script may not exist, or doesn't have execute (+x) permissions. What you have to do is locate your script inside the workflow’s folder and (with a terminal) do chmod +x /PATH/TO/SCRIPT/HERE, which will make it executable.

When you create the script directly from Alfred by setting the Text View source to Script, typing a name, and pressing Create, that is automatically done for you.

 

Hi vitor, thanks for the prompt and helpful reply.

 

I've tried both of your suggestions:

1) Manually creating `my_script.py` under the workflow directory, then navigating to the workflow directory, doing `chmod +x my_script.py` in the terminal, and then triggering the Text View again. Still the same permissions error.

2) Creating `my_script.py` via the Text View object itself, clicking "Create", and then triggering the Text View object. Still the same permissions error.

 

The only way I got it to work is by create a file with no extension, say `my_script` via Text View "Create". Then I open the created file and write `#!/usr/bin/python3` in the first line, followed by whatever my Python script has. This time triggering the Text View gives no permissions error.

 

It's a viable workaround but I do feel like it's a hassle not being able to work with an external script. Have you tried it on your machine? Not sure if it's a problem on my end. Thanks. 

[vitor]

You don’t have to remove the extension, but you do have to add the shebang. That’s not a workaround, but rather exactly the correct procedure in any Unix operation system (including macOS). This works exactly the same in the Script Filter if you use External Script as the mode of execution.

There is a difference between opening a file and executing it. The extension is irrelevant in the latter. For example, you could name your file my_script.rb (i.e. have a Ruby extension), but because you have the python shebang it will still execute correctly. This is normal and expected. Consider, for example, if you installed multiple interpreters for the same language (e.g. one for Python 2 and another for Python 3), and you have scripts in both languages (which, as you probably know are likely incompatible since Python broke backwards compatibility of a lot of things in the transition). How would the system know if a .py is for version 2 or 3? And how would it distinguish between opening for editing or for executing? The answer is the shebang, it’s what informs the system where to pipe that text file (the script) to the correct executable.

Conversely, let’s say that in a Script Filter you set your language to Bash or Zsh and then in the code have something like /usr/bin/python3 my_script.py. Again the extension is irrelevant, but in this case so is the shebang because you’re already telling the script how exactly you want the file to be executed. Or rather, you told the python interpreter to execute the file. In this case, you could even have a my_script.rb with the shebang #!/usr/bin/ruby, but because you said /usr/bin/python3 my_script.rb, then it will be executed by Python.

In other words, using the shebang or the interpreter are different ways of accomplishing the same thing. The shebang is an integral part of the execution model.

So to reiterate, your file can still be my_script.py but it does require the shebang.

[csjaugustus]

4 minutes ago, vitor said:

You don’t have to remove the extension, but you do have to add the shebang. That’s not a workaround, but rather exactly the correct procedure in any Unix operation system (including macOS). This works exactly the same in the Script Filter if you use External Script as the mode of execution.

There is a difference between opening a file and executing it. The extension is irrelevant in the latter. For example, you could name your file my_script.rb (i.e. have a Ruby extension), but because you have the python shebang it will still execute correctly. This is normal and expected. Consider, for example, if you installed multiple interpreters for the same language (e.g. one for Python 2 and another for Python 3), and you have scripts in both languages (which, as you probably know are likely incompatible since Python broke backwards compatibility of a lot of things in the transition). How would the system know if a .py is for version 2 or 3? And how would it distinguish between opening for editing or for executing? The answer is the shebang, it’s what informs the system where to pipe that text file (the script) to the correct executable.

Conversely, let’s say that in a Script Filter you set your language to Bash or Zsh and then in the code have something like /usr/bin/python3 my_script.py. Again the extension is irrelevant, but in this case so is the shebang because you’re already telling the script how exactly you want the file to be executed. Or rather, you told the python interpreter to execute the file. In this case, you could even have a my_script.rb with the shebang #!/usr/bin/ruby, but because you said /usr/bin/python3 my_script.rb, then it will be executed by Python.

In other words, using the shebang or the interpreter are different ways of accomplishing the same thing. The shebang is an integral part of the execution model.

So to reiterate, your file can still be my_script.py but it does require the shebang.

 

That totally solved it. Thanks a lot for your detailed explanation!