deanishe / alfred-workflow

Full-featured library for writing Alfred 3 & 4 workflows
https://www.deanishe.net/alfred-workflow/
Other
2.97k stars 232 forks source link

Python 3 Support #97

Open lazywei opened 8 years ago

lazywei commented 8 years ago

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.

deanishe commented 8 years ago

No Python 3. This is explained in the docs.

http://www.deanishe.net/alfred-workflow/supported-versions.html#python-versions

kimaldis commented 5 years ago

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?

deanishe commented 5 years ago

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.

r-richmond commented 5 years ago

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)

deanishe commented 5 years ago

Thanks for the link. Very important to know.

Time to reconsider?

Reconsider what?

r-richmond commented 5 years ago

Moving this library from python2 to python3

deanishe commented 5 years ago

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?

r-richmond commented 5 years ago

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

deanishe commented 5 years ago

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.

DanielThompson1 commented 5 years ago

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.

diemus commented 4 years ago

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

deanishe commented 4 years ago

I think golang is a better choice if you don't like python2

Apple just broke Go as a workflow language in Catalina.

diemus commented 4 years ago

@deanishe what do you mean?

deanishe commented 4 years ago

Catalina refuses to run unsigned binaries by default, so it's a massive PITA to get Go-based workflows to run.

kimaldis commented 4 years ago

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) `

deanishe commented 4 years ago

Alfred will probably take care of installing the runtimes if/when they disappear from macOS.

deanishe commented 4 years ago

BTW, which version of Py3 is installed on Catalina?

kimaldis commented 4 years ago

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.

deanishe commented 4 years ago

Apparently, it's 3.7.3.

deanishe commented 4 years ago

Re-opening this issue in the hope that people will post in here instead of adding new "Python 3?" issues.

wookayin commented 4 years ago

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?

deanishe commented 4 years ago

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.

NorthIsUp commented 3 years ago

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.

NorthIsUp commented 3 years ago

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 😂)

atanasj commented 3 years ago

@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?

SongshGeo commented 3 years ago

Hope for a py3 version ahhhh.

suochenxi commented 3 years ago

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 commented 3 years ago

@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?

EpicOrange commented 2 years ago

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'.)

mupi2k commented 2 years ago

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.

jeeftor commented 2 years ago

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 :)

NorthIsUp commented 2 years ago

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://github.com/NorthIsUp/alfred-workflow-scaffold

wayneyaoo commented 2 years ago

https://github.com/NorthIsUp/alfred-workflow-scaffold

@NorthIsUp I'm sorry but is this an intent to re-write the whole library to be in py3? finger crossed if so!

NorthIsUp commented 2 years ago

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.

EpicOrange commented 2 years ago

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://github.com/NorthIsUp/alfred-workflow-scaffold

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!

xavdid commented 2 years ago

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.

tomy0000000 commented 2 years ago

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.

notabene00 commented 2 years ago

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

tomy0000000 commented 2 years ago

@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.

vitorgalvao commented 2 years ago

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.

psifertex commented 2 years ago

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.

tomy0000000 commented 2 years ago

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.

tilmanginzel commented 2 years ago

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! 👍

jeeftor commented 2 years ago

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.

NorthIsUp commented 2 years ago

(I merged Tommy's patch)

pat-s commented 2 years ago

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 💪

wollew commented 2 years ago

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.

tomy0000000 commented 2 years ago

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.

jeeftor commented 2 years ago

So @deanishe looks like he hasn't been active since Jan ...

image

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

jeeftor commented 2 years ago

I sent him a message on the Alfred forum ... hopefully we'll get a reply on timeline/plans...