-
Notifications
You must be signed in to change notification settings - Fork 234
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Python 3 Support #97
Comments
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
Additionally it looks like users are going to have to get comfortable installing additional things outside of alfred anyways
|
Thanks for the link. Very important to know.
Reconsider what? |
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?
|
Not yet, by the looks of it. Presumably that will happen in the version after Catalina, when Py2 will be EOL, anyway.
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, |
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 |
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? |
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. |
If avoiding any kind of user interaction is the goal here, running |
Also, the PKG approach would keep the user at an arbitrary Python version (whatever the library installs) which could lead to inconsistencies down the line. Especially because PKGs can be harder to get rid of entirely. |
@xilopaint is your fork available to use? I'm looking into options for fixing my popular workflow: https://github.com/benknight/hue-alfred-workflow |
@benknight I don't have a public repo yet as I still have to work on the documentation and the test suit, but you can copy the Unless @deanishe resume his work with Alfred-Workflow my version will be released in a new repo with the name Alpynist with credits to him and this repo. This is because @deanishe may prefer not having any affiliation with some library he's not maintaining so I'm giving it a new name. Please, notice the |
@xilopaint thanks for the update. I will try plugging it in and let you know if there are any issues. |
Hello, is there anyupdate on how to make it working again with py3? |
I believe this is what you're looking for: NorthIsUp/alfred-workflow-py3. |
thank for your contribution, really help me solve problem |
@YuHoYe - have you looked at the other forks posted on this thread? |
|
@YuHoYe do you mean my fork? I'm not aware of any issues with background jobs. It's actually one of the issues I've fixed in regards to @NorthIsUp fork If you or anyone else using my fork have any issues I'd be glad to look into it. Btw, I'm close to a public release. |
@xilopaint I would love to test and use your repo, please let me know if I can test and use it! |
@coolhva sure, you just need to download the workflow folder from my Alfred PDF Tools workflow. I haven't published a repo for the library yet. |
@xilopaint Thanks for the wonderful port to Python3.. I have now moved three of my workflows to Python3 using your port! AAdvantage EShopping And for the most part it was a drop-in replacement. Two things I had to work on outside of making my own code Python3 compatible: web.post has a different order of parameters from before (so I had to add in named parameters that I had not done before) I had to only change 1 line in your workflow.py That was needed because some of my objects were dicts I think, and I got an error saying you could not compare dicts, and looking things up on google, it showed that sorting behavior has changed in Python3 from Python 2.7 especially when there are single element dicts/arrays, etc. |
@xilopaint whed do you plan to publish py3 fork? |
Basically as far as we can tell this project is dead and it’s been forked.
…Sent from my iPhone
On May 23, 2022, at 8:00 AM, Tomy Hsieh ***@***.***> wrote:
Hello, is there anyupdate on how to make it working again with py3?
@esseti
I believe this is what you're looking for: NorthIsUp/alfred-workflow-py3.
Though this is a long thread, but if you read from the bottom upwards, you should be find some helpful information within this year.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
|
I’m getting to the point where there are multiple open issues on my workflows for people with new OS X installs sans puthon2
…Sent from my iPhone
On Mar 17, 2022, at 3:41 PM, Vítor Galvão ***@***.***> wrote:
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.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
|
@xilopaint I found a potential bug in deadnishe's codebase and have some thoughts on how to patch it. Would you like me to participate in your fork? |
@tomy0000000 If the bug is also present in my fork you can submit a PR to my Alfred PDF Tools workflow. |
@kiddick I still need to finish the test suite. I'll try to do it in the coming days but can't promise anything as I'm involved in another project that is consuming a lot of my time. |
* Use @xilopaint’s fork of @deanishe’s Workflow module - See deanishe/alfred-workflow#97 for details * Format using black * Add shebang & call script directly
@schwark It's fixed. Thanks for pointing it out. |
Hi, everyone, I created a Python3-compatible Alfred library based on this repository: ualfred, You are welcome to try it out and make any suggestions and report bugs. |
Summarising some of the earlier python3 compatible forks/options mentioned above as well, so that they're all in one place for people: History of Forks
Summary of ForksSo to summarise all of the above forks:
See also: |
pull requests welcome! |
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.
The text was updated successfully, but these errors were encountered: