Open lazywei opened 8 years ago
No Python 3. This is explained in the docs.
http://www.deanishe.net/alfred-workflow/supported-versions.html#python-versions
As I understand it, 2.7 will not be supported beyond 2020. I've no idea how that affects MacOS but do you have any thoughts on this regards Alfred?
From my POV, nothing much has changed. Python 2.6 support is no longer required, seeing as Alfred 3 only supports version of macOS with 2.7.
But I'm not inclined to add Python 3 support myself until Apple starts shipping it with macOS.
Time to reconsider? 2.7 is being removed from future versions of macOS.
https://developer.apple.com/documentation/macos_release_notes/macos_10_15_beta_release_notes
Use of Python 2.7 isn’t recommended as this version is included in macOS for compatibility with legacy software. Future versions of macOS won’t include Python 2.7. Instead, it’s recommended that you run python3 from within Terminal. (51097165)
Additionally it looks like users are going to have to get comfortable installing additional things outside of alfred anyways
Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app. (49764202)
Thanks for the link. Very important to know.
Time to reconsider?
Reconsider what?
Moving this library from python2 to python3
Moving this library from python2 to python3
I don’t follow you. I said I wouldn’t support Py3 until Apple shipped it.
What part of that do you want me to reconsider?
I suppose I made an assumption based off your previous statement. More explicitly you've said you don't want end-users to be forced to install needless external dependencies. However, since Apple is removing python2 from macOS users will be forced to install an external dependency to run workflows built using this repo. And finally, I assumed that since end-users are going to be forced to install an external dependency you'd agree that the dependency might as well be python3 instead of python2.
But that was just my assumption; What are your actual thoughts / opinion given this announcement?
But to be very clear: I have zero interest in Py3 support until Py3 is part of macOS. I'm not interested in helping people write workflows with needless external dependencies like Py3. It's a crappy, user-hostile way of going about writing a workflow, and I don't want to encourage it. ... My personal preference would be for a Py3-only rewrite once it is included in macOS. source
However, since Apple is removing python2 from macOS
Not yet, by the looks of it. Presumably that will happen in the version after Catalina, when Py2 will be EOL, anyway.
My personal preference would be for a Py3-only rewrite once it is included in macOS.
That’s what I’ll do. I’ll release Alfred-Workflow 2 with a new API.
It’ll be Py3 and Alfred 4+ only. There’s no point messing around to support EOL’ed Python and Alfred versions.
It’ll also give me a chance to tidy up the rather ugly API and remove a lot of cruft that’s only there to support old versions of Alfred.
Hey Deanishe, I found out about you from the Alfred blog. First I wanted to say I am amazed at all the work you have done and the amount of workflows you have coded. I am currently volunteering for a tech startup, We know potential users of our software value productivity, moving fast, are keen on using the keyboard to navigate fast, and many are already using small utility tools such as Alfred. Basically I was hoping you could help me answer a few questions to aid in the development of our software. Please let me know if your interested for a chat and we can arrange opening up some communication. Thanks for reading and hope to hear from you soon.
since alfred only works on macOS and Apple is removing python2 from macOS, I think golang is a better choice if you don't like python2
I think golang is a better choice if you don't like python2
Apple just broke Go as a workflow language in Catalina.
@deanishe what do you mean?
Catalina refuses to run unsigned binaries by default, so it's a massive PITA to get Go-based workflows to run.
Adding to the mix, grabbed from the Catalina 10.15 release notes: and with 2.7 now officially dead, I’m wondering where we go from here
`Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app. (49764202)
Use of Python 2.7 isn’t recommended as this version is included in macOS for compatibility with legacy software. Future versions of macOS won’t include Python 2.7. Instead, it’s recommended that you run python3 from within Terminal. (51097165) `
Alfred will probably take care of installing the runtimes if/when they disappear from macOS.
BTW, which version of Py3 is installed on Catalina?
As far as I'm aware, it's not.
I understand the reasons why but it's still a continuing frustration that I can't choose what version of Python I'd like to use.
Apparently, it's 3.7.3.
Re-opening this issue in the hope that people will post in here instead of adding new "Python 3?" issues.
It's 2020. We should make it compatible with python3. What is your plan for v2? If you do not have one, can I work on this?
It's 2020. We should make it compatible with python3.
Yes, I understand the Python situation. But this library isn't targeted at Python, it's targeted at Alfred (and by extension, macOS).
As noted in the docs, the goal of this library is to enable people to write workflows that work out of the box with Alfred, which means system Python only.
As Python 3 isn't available (by default) on any version of macOS before Catalina, and a lot of people are avoiding Catalina because it's a bug-addled mess, Py3 simply isn't a massive priority at this time.
I completely understand where you Py3 fans are coming from, and how much easier Py3 makes writing workflows, but as far as I'm concerned, user convenience is far more important than developer convenience. Specifically, that means that I believe developers should suck it up rather than requiring (most) users to install a non-standard runtime via Homebrew or whatever.
The bottom line is that Py2 is available on every version of macOS that Alfred supports, but Py3 isn't. So Py2 is still the target runtime.
Python is a very popular language for workflows, and I don't want to cause the same kind of nightmare for users (and also developers via the inevitable support requests) that the JS community has by basing a bunch of workflows on a runtime (Node) that isn't included with macOS.
A Py3 version of the library is coming. It's just not a pressing concern right now while Py3 is only available on a small minority of the machines running Alfred/macOS.
python3 is system python now. and making it work in python3 doesn't mean it won't work in python2. it just means using a compatibility layer.
Hey all, I looked into it and this is a really really complicated project, so I did a python3 port but was unable to keep python2 compatibility. Unit tests pass but I haven't done thorough testing by any means.
check it out here: https://github.com/NorthIsUp/alfred-workflow-py3
I'll be maintaining this for personal usage until this project does it officially (Read: PRs welcome, but don't count on me for support 😂)
@NorthIsUp, I've been having issues with the Py2 version of this workflow and was hoping to use your Py3 version, however have no idea how to get this working and there seems to be no pre-packaged workflow file. Any tips on what to do?
Hope for a py3 version ahhhh.
WARNING: Python 2.7 is not recommended. This version is included in macOS for compatibility with legacy software. Future versions of macOS will not include Python 2.7. Instead, it is recommended that you transition to using 'python3' from within Terminal.
@NorthIsUp, I've been having issues with the Py2 version of this workflow and was hoping to use your Py3 version, however have no idea how to get this working and there seems to be no pre-packaged workflow file. Any tips on what to do?
I don't get the question, it is the exact same api as the python2 version. can you elaborate?
API change for anyone here switching to the above Python 3 repo by @ NorthIsUp: use requests
rather than the old web.py
previously included in this library.
Old Python 2 workflow:
from workflow import Workflow, web
...
r = web.get(url)
New Python 3 workflow:
from workflow import Workflow3
import requests
...
r = requests.get(url)
As a consequence, you'll have to work with a dependency, requests>=2.25,<3
. (I'll defer explaining how to handle dependencies in Alfred workflows to someone else -- on Big Sur, I managed to get away with /usr/bin/pip3 install 'requests>=2.25,<3'
.)
https://developer.apple.com/documentation/macos-release-notes/macos-12_3-release-notes#Python
Alfred's official stance appears to be: if you are a developer, port your workflow to python3. Are we actually going to get a python3 version or is the preferred solution to switch to @NorthIsUp 's version? No disrespect intended (the current Alfred-Workflow is remarkable), but MacOS has had python3 bundled since Catalina, 3 major versions and almost 3 years ago. I have users I support being switched to Monterrey, and getting the "your plugins won't work soon" dialog. Given the quality of the python2 version of this toolkit, I highly prefer to wait until we have a working v2, but we can't wait forever.
I just got a request for one of my workflows where a user on 12.3 beta can't run it... due to python3 issues ... so the clock's a ticking :)
As a consequence, you'll have to work with a dependency,
requests>=2.25,<3
. (I'll defer explaining how to handle dependencies in Alfred workflows to someone else -- on Big Sur, I managed to get away with/usr/bin/pip3 install 'requests>=2.25,<3'
.)
@NorthIsUp I'm sorry but is this an intent to re-write the whole library to be in py3? finger crossed if so!
no rewrite necessary, I forked and updated @deanishe's great work: https://github.com/NorthIsUp/alfred-workflow-py3
the scaffold is to just to help develop and package the workflows.
As a consequence, you'll have to work with a dependency,
requests>=2.25,<3
. (I'll defer explaining how to handle dependencies in Alfred workflows to someone else -- on Big Sur, I managed to get away with/usr/bin/pip3 install 'requests>=2.25,<3'
.)
Indeed! My comment was more intended for people migrating existing workflows that they didn't write (i.e. the compiled/installed output of this scaffold).
Thanks for maintaining this fork!
In a recent macOS (12.3), Apple stopped shipping Python 2 at all: /usr/bin/python
gives command not found
. Thus, any workflow using this now fails silently.
/usr/bin/python3
is 3.8.9
.
For any workflow maintainer, I have a fork tomy0000000/alfred-workflow-py3 based on @NorthIsUp's fork NorthIsUp/alfred-workflow-py3, which works perfectly fine on my workflow Coinc.
See NorthIsUp/alfred-workflow-py3#2 for more.
And for this to work every user should install brew
, install python3
, then do ln -s /opt/homebrew/bin/python3 /opt/homebrew/bin/python
?
Or you wish to use it as a bash
script with python3 main.py
in the script filter
e.g.?
Maybe there's a better way that's out of my sight
@tomy0000000
@notabene00
The bottom line is: we need user to install python on their own, and Homebrew is currently, to the best of my knowledge, the most simple way to install and configure python into a consistent, acceptable and predictable standard.
Given that homebrew is installing python into different path in Apple Silicon/Intel, this is what I put in the workflow script filter (edited from homebrew's install script):
UNAME_MACHINE="$(/usr/bin/uname -m)"
if [[ "${UNAME_MACHINE}" == "arm64" ]]
then
HOMEBREW_PREFIX="/opt/homebrew"
else
HOMEBREW_PREFIX="/usr/local"
fi
if command -v "$HOMEBREW_PREFIX/bin/python3" 1>/dev/null 2>&1; then
$HOMEBREW_PREFIX/bin/python3 main.py convert $1
fi
That way, no symbolic link is required.
The bottom line is: we need user to install python on their own, and Homebrew is currently, to the best of my knowledge, the most simple way to install and configure python into a consistent, acceptable and predictable standard.
Someone who has Homebrew also has the Apple Developer Tools (they’re a prerequisite) and those install /usr/bin/python3
(which is an old version: 3.8.9
). Some Workflow developers are opting to require that instead, so a fork of this library should be able to work with that version while preferring a Homebrew Python if available.
Given that homebrew is installing python into different path in Apple Silicon/Intel, this is what I put in the workflow script filter
There is a much simpler and portable solution. Start the shell script with export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}"
and then just call python3 YOUR_SCRIPT
or use #!/usr/bin/env python3
has a shebang.
That will use the correct Python installation from Homebrew (no matter if Intel or Apple Silicon) or from the Developer Tools if available. Plus, if not available, macOS will show a GUI prompt allowing the user to install the Developer Tools (and thus Python) in two clicks.
I disagree that homebrew is the best / most predictable way to install python. Developer Tools is a single click. Homebrew requires multiple steps and their python versions are a moving target.
To be honest I don't know Apple ships Python 3.8.9 in Xcode Command Line Tools until now. That's probably a good option to go with, but I wonder how long will Apple continues to do so.
Anyway, no matter which executable you're choosing, there should be no compatible issue on using tomy0000000/alfred-workflow-py3 or NorthIsUp/alfred-workflow-py3.
Yup, just want to chime in and say that NorthIsUp/alfred-workflow-py3 with @tomy0000000's patch https://github.com/NorthIsUp/alfred-workflow-py3/pull/2 works like a charm. Migration in my workflow was smooth, thanks a lot! 👍
I’m also using this fork - however one of my workflow itself has lots of python 2 specific crap I needed to modify
Sent from my iPhone
On Mar 20, 2022, at 7:24 AM, Tilman Ginzel @.***> wrote:
Yup, just want to chime in and say that NorthIsUp/alfred-workflow-py3 with @tomy0000000's patch NorthIsUp#2 works like a charm. Migration in my workflow was smooth, thanks a lot! 👍
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.
(I merged Tommy's patch)
I am planning to make the migration within the next days. I am wondering which fork I should use - ideally I don't want to switch again in a few months :)
I know this is not a straightforward discussion but maybe asking directly: @NorthIsUp and @tomy0000000 - any plans to collaborate or focus on one of your forks? Would make it easier for other folks to move forward :)
Thanks for your contributions and help 💪
I'd be interested in a statement from Dean, if he's willing to merge the code from the fork or (very) soon going to provide his own port to Python3. If not, this repo will soon be dead, which would be a shame.
I know this is not a straightforward discussion but maybe asking directly: @NorthIsUp and @tomy0000000 - any plans to collaborate or focus on one of your forks? Would make it easier for other folks to move forward :)
Since my fork had merged into @NorthIsUp's, you should be using his.
So @deanishe looks like he hasn't been active since Jan ...
I'll go take a peak at the Alfred forum - but it would be nice to figure out if he plans to update or if I should start contributing elsewhere
I sent him a message on the Alfred forum ... hopefully we'll get a reply on timeline/plans...
Hi,
Any plan for supporting Python 3? Switching to python 3 enjoys some benefits such as text encoding and better built-in library. I'm wondering if you have any thought on it.
Thanks.