Using python3 in Run Script blocks?

[Chris Messina]

I expected that /usr/bin/python would be python3, but it turns out that (on my system) it's Python 2.7.18. 

 

A script that I'd like to use in a File Action requires python3, and selecting python from this list causes errors in the console.

 

 

Is it possible to tell Alfred to use python3 to run the script?

[vitor]

8 hours ago, Chris Messina said:

I expected that /usr/bin/python would be python3, but it turns out that (on my system) it's Python 2.7.18. 

That’s not an oddity of your system, it’s expected. It isn’t worth going into the Python 2/3 kerfuffle here but don’t expect that to ever be updated on macOS. Apple is actively removing scripting languages and no longer updates them.

 

8 hours ago, Chris Messina said:

and selecting python from this list causes errors in the console.

Because you’re using Python3 features. macOS has never shipped Python3, though it installs it with the developer tools.

 

9 hours ago, Chris Messina said:

Is it possible to tell Alfred to use python3 to run the script?

Yes, but you can’t paste the script into the box. There are a few ways to do it; one is to set it as /bin/bash then /full/path/to/python3 /path/to/your/script.

 

Note that using Python3 currently makes your Workflow harder to share, which you may or not care about. There are plenty of Python3 Workflows shared on the forum (e.g. by @Acidham) so look at those for ideas.

[deanishe]

10 hours ago, Chris Messina said:

I expected that /usr/bin/python would be python3

 

That’s easy enough to check, isn’t it? /usr/bin/python is always Python 2. Python 3 is /usr/bin/python3 (and part of the developer tools, as Vítor noted).

 

10 hours ago, Chris Messina said:

Is it possible to tell Alfred to use python3 to run the script?

 

The best thing to do with Python 3 is to use bash/zsh and set export PATH=/opt/homebrew/bin:/usr/local/bin:$PATH at the top of the script. Then call your workflow just using python3 (e.g. python3 myscript.py "$1" or with the shebang #!/usr/bin/env python3

 

That way, the workflow should work with either Homebrew Python 3 or the one from Apple's developer tools.

 

You shouldn't use Python 2, even though it is installed, because it's dead. It will never be updated again.

[giovanni]

12 minutes ago, deanishe said:

The best thing to do with Python 3 is to use bash/zsh and set export PATH=/opt/homebrew/bin:/usr/local/bin:$PATH at the top of the script.

would you recommend to do that for each script (ie every time you invoke Python3), or once per workflow? eg, if you have multiple chained script filters, each invoking Python3, should every call be preceded by the export command?

[deanishe]

2 minutes ago, giovanni said:

should every call be preceded by the export command?

 

Yes. It won't work otherwise.

[Chris Messina]

On 1/26/2022 at 4:42 AM, deanishe said:

The best thing to do with Python 3 is to use bash/zsh and set export PATH=/opt/homebrew/bin:/usr/local/bin:$PATH at the top of the script. Then call your workflow just using python3 (e.g. python3 myscript.py "$1" or with the shebang #!/usr/bin/env python3

 

That way, the workflow should work with either Homebrew Python 3 or the one from Apple's developer tools.

 

You shouldn't use Python 2, even though it is installed, because it's dead. It will never be updated again.

 

Ok, thank you. As I said, since I don't follow Python closely, I just assumed that Alfred would use the latest version, but obviously that's not the case — by default. 

 

It might be nice if the information you shared about python2 vs python3 were available in an info button when selecting /usr/bin/python from the dropdown, or perhaps Alfred could indicate which version of python is being selected with subtext in the menu. I'm not sure I would have figured out why my script wasn't working without your guidance.

 

As it stands, without some kind of disclosure, it seems like Alfred is implicitly endorsing the use of the system python library since there are no warnings that it's deprecated.

[vitor]

11 hours ago, Chris Messina said:

It might be nice if the information you shared about python2 vs python3 were available in an info button

The transition from Python 2 to 3 took over a decade and is extremely well-known (in the whole field) for how annoying it was. Even basic tutorials these days are likely to mention it. If it was news to you, that is both a fluke and good news.

 

11 hours ago, Chris Messina said:

or perhaps Alfred could indicate which version of python is being selected with subtext in the menu.

That would be clutter. It is the purview of the person programming to determine that because it depends. It isn’t hard at all and you figured it out. That is good, and if you plan on writing more code you absolutely must get used to it. From here on out it only becomes more complex and there is no handholding. Learning how to understand what’s happening and how to fix it will be a crucial skill.

 

11 hours ago, Chris Messina said:

I'm not sure I would have figured out why my script wasn't working without your guidance.

I don’t believe that. You did figure it out. Right on the first post you mention the different versions! Then you took the correct next step: tried to fix it yourself and asked for help when you felt you were at your limit. Good job! Now you’re programming; that’s all part of it. Do you think I or Dean never have questions? Everyone relies on other people sometimes.

 

I didn’t want to overwhelm you on the first reply and do think that at this point you’ll benefit from experimenting and making mistakes, but the fixes we offered you are documented. At some point in the near future it will be useful for you to understand that model.

 

12 hours ago, Chris Messina said:

As it stands, without some kind of disclosure, it seems like Alfred is implicitly endorsing the use of the system python library since there are no warnings that it's deprecated.

The situation isn’t as clear-cut as that. Try Ruby in the Terminal and you’ll get a scary message too. Should Alfred also warn about that? Definitely not! The only reason the message exists is Apple put it there. We didn’t need to be in this situation; we are because they chose it.

 

It’s irrelevant to discuss that at this point. The Alfred community has known of these deprecations from the start and the path forward is implementing a solution, not adding caveats to the old method.

[Chris Messina]

13 hours ago, vitor said:

I don’t believe that. You did figure it out. Right on the first post you mention the different versions! Then you took the correct next step: tried to fix it yourself and asked for help when you felt you were at your limit. Good job! Now you’re programming; that’s all part of it. Do you think I or Dean never have questions? Everyone relies on other people sometimes.

 

To be fair, I actually "figured it out" because I was DM'ing w/ @mcskrzypczak and was working to diagnose my issues. But I take your point.

 

13 hours ago, vitor said:

The transition from Python 2 to 3 took over a decade and is extremely well-known (in the whole field) for how annoying it was. Even basic tutorials these days are likely to mention it. If it was news to you, that is both a fluke and good news.

 

Just saw this — is your position consistent with this upcoming change in macOS Monterey 12.3 Beta?

 

[vitor]

10 hours ago, Chris Messina said:

is your position consistent with this upcoming change in macOS Monterey 12.3 Beta?

 

Yes. Python’s transition has nothing to do with Apple and that change isn’t news. Though it is bad form of them to do the deprecation in a point release rather that a major release.

[Chris Messina]

6 hours ago, vitor said:

Though it is bad form of them to do the deprecation in a point release rather that a major release.

 

It is quite unconventional. 

 

What implication might this have on Alfred's dropdown list of Languages after macOS 12.3?

[Tsunami]

2 hours ago, Chris Messina said:

What implication might this have on Alfred's dropdown list of Languages after macOS 12.3?

 

Given that /usr/bin/php was removed in macOS 12.0 and it's still in the dropdown, probably none until Alfred drops support for macOS versions that still ship those binaries.

Edited January 29, 2022 by Tsunami

[vitor]

Just now, Tsunami said:

Given that /usr/bin/php was removed in macOS 12.0 and it's still in the dropdown, probably none.

 

Yep. Pretty much. The workaround might be different because Homebrew no longer ships Python 2 in the core tap. As for its impact on Workflows, we’ll have to wait and see. (In the grand scheme) There weren’t that many popular ones written in PHP and still working, and for a while now new Python Workflows (that I’m aware of) have required Python 3, meaning many people won’t even notice.

 

@deanishe’s older Workflows (and Workflows using his library) may be affected because (unless I’m misremembering) his Workflows always used the builtin-in Python (thumbs up; no dependencies and fewer instructions) until he abandoned it for Go.

[deanishe]

36 minutes ago, vitor said:

@deanishe’s older Workflows (and Workflows using his library) may be affected because (unless I’m misremembering) his Workflows always used the builtin-in Python (thumbs up; no dependencies and fewer instructions) until he abandoned it for Go

The library isn't Python 3-compatible. The plan was to rewrite the whole API for Python 3. There's a lot of Alfred 2-vintage crap that can be thrown away.

 

Now I'm thinking I should release a Python 3-compatible version of the existing one. Because the library uses Unicode throughout, it's possible that some workflows based on it might work on Python 3 with just an updated version of the library.

 

Broadly speaking, I'd imagine every Python workflow needs at least the shebang/interpreter path changing, and a very large proportion will also need code changes. Hard to say for sure. Anyone who was doing text handling properly in Python 2 (i.e. properly decoding and encoding text) will need to fix their workflows. Anyone who was just using bytestrings may not need to change any code.

[Andrew]

I will be making a few tweaks in the next release.

 

The config for Run Script / Script Filter now does a check to see if the language is available and adds a [not installed] on the language selection for missing bins. I have also added a comment to the example Python script (when selecting the Python language) which highlights the impending issue.

 

[Tekl]

The detection of python is a good addition. But how can we use Python at all? I can't select Python3 from the Dev Tools or from Homebrew. Why not adding python3 to the drop down menu like /opt/homebrew/bin/php?

[Chris Messina]

19 hours ago, Tekl said:

Why not adding python3 to the drop down menu like /opt/homebrew/bin/php?

 

Because the user would have to install Homebrew AND Python to make that a viable option. It's unclear if or whether @Andrew would be open to enabling integration of Alfred and Homebrew (i.e. detecting whether Homebrew is installed). For example, Alfred could offer to install Python via Homebrew if a Workflow attempts to execute a Python command, similar to Xcode's Developer Tools:

 

[vitor]

Technically, for this specific case, just installing the Developer Tools is enough because they ship Python 3.

 

If you use External Script to a script with the right shebang or /bin/bash calling /usr/bin/python3, you get that GUI prompt and Python 3 is installed.

 

Because Homebrew requires the Developer Tools, just installing Homebrew and doing nothing else already guarantees a Python 3 version. It’s a version from 2019, though; don’t assume Apple will keep it up with the times.
 

@Chris Messina is right. A Python from Homebrew is preferable, and because that cannot be guaranteed to exist on a user’s computer it wouldn’t work to simply list it in the dropdown without something extra.

Edited February 1, 2022 by vitor

[Tekl]

Thanks for your replys.

 

The problem with external scripts is, that I've existing Workflows by other authors which depend on /usr/bin/python. So I have to understand such workflows, to get everything fixed und convert them to external files. It would be easier if I could just select an alternative path to python. At least /usr/bin/python3 should be included into the drop down menu.

[vitor]

@Tekl That wouldn’t work. You can’t guarantee a Python 2 script works with Python 3, that’s why the transition was such a mess. Plus, if those developers used External Scripts themselves, the dropdown doesn’t matter.

 

Right now what you want is to recover Python 2. Alfred will pick that up, just like it does with PHP.

[deanishe]

39 minutes ago, vitor said:

You can’t guarantee a Python 2 script works with Python 3

Only the most trivial Python 2 programs run unchanged under Python 3. That might include a fair few Workflows, however.

 

But no, just pointing Python 2 programs at a Python 3 interpreter isn't a solution. This is going to be a huge shitshow, imo. Most workflows will need rewriting and all users will need to install developer tools.

 

Until Andrew adds some kind of PATH-altering feature to activate Homebrew, the best way to use Python 3, imo, is to use a shell wrapper and alter PATH yourself:

export PATH=/opt/homebrew/bin:/usr/local/bin:$PATH

 

python3 myscript.py

In any case, it'll still be a pain in the backside for users because there's no way around installing some developer tools.

 

JXA is probably the only straightforward way to write workflow scripts any more. Python and PHP are gone, Ruby's days are surely numbered. Compiled workflow binaries require signing to avoid stupid, scary warnings. JXA is probably the only semi-sensible language that will remain part of macOS.

Edited February 2, 2022 by deanishe

[deanishe]

1 hour ago, vitor said:

what you want is to recover Python 2.

Yeah, this bit isn't true:

 

Workflow developers writing Python mostly switched to version 3, so chances are you won't notice the change.

 

Most workflows are written in Python 2 because it was part of macOS. Python 3 has always required installing some form of dev tools (i.e. it's a pain for users).

[vitor]

1 minute ago, deanishe said:

Most workflows are written in Python 2 because it was part of macOS. Python 3 has always required installing some form of dev tools (i.e. it's a pain for users).

 

This is purely observational, but for a while now every time I see a new Python Workflow submitted to the forum it requires Python 3.

[deanishe]

35 minutes ago, vitor said:

for a while now every time I see a new Python Workflow submitted to the forum it requires Python 3.

Yeah. Python 2 was EOL'ed in 2020. It would have been a bit questionable to start a new workflow in Python 2 after that.

 

The death of Python 2 was always going to be a big problem in workflow land, but Apple removing Python completely is a real kick in the nuts.

 

I suppose the sensible thing to do going forwards is to target Homebrew Python. Most users are going to have to install Homebrew, anyway.

Edited February 2, 2022 by deanishe

[Chris Messina]

Noticed these updates in Alfred 4.6.3 Pre-release (Build 1282):

 

Quote

 

Workflow Run Script / Script Filter tweaks

• Add a note to the default example Python workflow script to warn of deprecation, and removal in macOS 12.3+

• Do a bin existence check and add [not installed] to the popup selection box on any paths which are not available

 

 

Which looks like this when you create a new Run Script/Script Filter block: