Skip to content
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

Open
lazywei opened this issue Aug 2, 2016 · 80 comments
Open

Python 3 Support #97

lazywei opened this issue Aug 2, 2016 · 80 comments

Comments

@lazywei
Copy link

lazywei commented Aug 2, 2016

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
Copy link
Owner

deanishe commented Aug 2, 2016

No Python 3. This is explained in the docs.

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

@kimaldis
Copy link

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
Copy link
Owner

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
Copy link

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
Copy link
Owner

deanishe commented Jun 4, 2019

Thanks for the link. Very important to know.

Time to reconsider?

Reconsider what?

@r-richmond
Copy link

Moving this library from python2 to python3

@deanishe
Copy link
Owner

deanishe commented Jun 4, 2019

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
Copy link

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
Copy link
Owner

deanishe commented Jun 5, 2019

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
Copy link

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
Copy link

diemus commented Oct 11, 2019

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
Copy link
Owner

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

Apple just broke Go as a workflow language in Catalina.

@diemus
Copy link

diemus commented Oct 12, 2019

@deanishe what do you mean?

@deanishe
Copy link
Owner

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

@kimaldis
Copy link

kimaldis commented Jan 2, 2020

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
Copy link
Owner

deanishe commented Jan 2, 2020

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

@deanishe
Copy link
Owner

deanishe commented Jan 2, 2020

BTW, which version of Py3 is installed on Catalina?

@kimaldis
Copy link

kimaldis commented Jan 2, 2020

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
Copy link
Owner

deanishe commented Jan 2, 2020

Apparently, it's 3.7.3.

@deanishe
Copy link
Owner

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

@deanishe deanishe reopened this Feb 18, 2020
@wookayin
Copy link

wookayin commented Mar 20, 2020

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 deanishe pinned this issue Mar 29, 2020
@deanishe
Copy link
Owner

deanishe commented Jun 15, 2020

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.

@glyph
Copy link

glyph commented May 5, 2022

If avoiding any kind of user interaction is the goal here, running xcode-select --install will prompt to install the Xcode command-line tools, which, as others have observed, include a copy of python3. You could also have a shell script that does something like curl -LO https://www.python.org/ftp/python/3.10.4/python-3.10.4-macos11.pkg && installer -target / -pkg python-3.10.4-macos11.pkg which would silently install a Python.org python in the background.

@vitorgalvao
Copy link

You could also have a shell script that does something like curl -LO https://www.python.org/ftp/python/3.10.4/python-3.10.4-macos11.pkg && installer -target / -pkg python-3.10.4-macos11.pkg which would silently install a Python.org python in the background.

installer will likely need sudo, so that’s a no go. Plus, the user would be faced with a long wait without knowing what’s happening. The Developer Tools prompt is clear and done with in two clicks. And if the user has Homebrew, it won’t show because it’s already installed.

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.

@benknight
Copy link

@NorthIsUp - I've run into a bunch of potentially special uses cases where I found the Py3 fork isn't really working well:

  • Auto-update support
  • Background support (not working correctly)

That being said -> considering lack of input from @deanishe - I'm at a bit of a loss with what he wants to do with this library...

I have fixed these issues and others. I think I have a fully functional library at this moment with a cleaner codebase. @vitorgalvao, moderator of Alfred Forum, suggested me to take over the library as a community-approved successor. But I'm still waiting for @deanishe's decision about the future of the lib.

@NorthIsUp, whose work was partly adopted in my private project, can be defined as a collaborator of the repo with privileges to commit changes unless he prefers to start his own repo.

In any case I'm still waiting for @deanishe to share his perspective. An official update is still the best option.

@xilopaint is your fork available to use? I'm looking into options for fixing my popular workflow: https://github.com/benknight/hue-alfred-workflow

@xilopaint
Copy link

xilopaint commented May 7, 2022

@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 workflow folder from the repository of my Alfred PDF Tools workflow. I still have some work to make the codebase compliant with Pylint but this part is almost done. It's already compliant with Black and Bandit.

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 Workflow3 class no longer exist in my version and you should just use Workflow instead. Also, my version may not be compatible with Alfred 2 and 3. My goal is supporting Alfred from v4.

@benknight
Copy link

@xilopaint thanks for the update. I will try plugging it in and let you know if there are any issues.

@esseti
Copy link

esseti commented May 23, 2022

Hello, is there anyupdate on how to make it working again with py3?

@tomy0000000
Copy link

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.

@YuHoYe
Copy link

YuHoYe commented Jul 14, 2022

@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 workflow folder from the repository of my Alfred PDF Tools workflow. I still have some work to make the codebase compliant with Pylint but this part is almost done. It's already compliant with Black and Bandit.

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 Workflow3 class no longer exist in my version and you should just use Workflow instead. Also, my version may not be compatible with Alfred 2 and 3. My goal is supporting Alfred from v4.

thank for your contribution, really help me solve problem

@jeeftor
Copy link

jeeftor commented Jul 29, 2022

@YuHoYe - have you looked at the other forks posted on this thread?

@YuHoYe
Copy link

YuHoYe commented Aug 1, 2022

@YuHoYe - have you looked at the other forks posted on this thread?
@jeeftor no, I just use the fork from @benknight ,it seem work good in python 3 except background job.

@xilopaint
Copy link

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

@coolhva
Copy link

coolhva commented Aug 16, 2022

@xilopaint I would love to test and use your repo, please let me know if I can test and use it!

@xilopaint
Copy link

xilopaint commented Aug 18, 2022

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

@schwark
Copy link

schwark commented Aug 19, 2022

@xilopaint Thanks for the wonderful port to Python3.. I have now moved three of my workflows to Python3 using your port!

AAdvantage EShopping
SmartThings
UniFi

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
from: workflow.py:2131 results.sort(reverse=ascending)
to: workflow.py:2131 results.sort(key=lambda x: x[0], reverse=ascending)

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.

https://stackoverflow.com/questions/55695479/typeerror-not-supported-between-instances-of-dict-and-dict

@kiddten
Copy link

kiddten commented Oct 7, 2022

@xilopaint whed do you plan to publish py3 fork?

@jeeftor
Copy link

jeeftor commented Oct 11, 2022 via email

@jeeftor
Copy link

jeeftor commented Oct 11, 2022 via email

@tomy0000000
Copy link

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

@xilopaint
Copy link

@tomy0000000 If the bug is also present in my fork you can submit a PR to my Alfred PDF Tools workflow.

@xilopaint
Copy link

@xilopaint whed do you plan to publish py3 fork?

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

jeffbyrnes added a commit to jeffbyrnes/alfred-spongebob-mocking-text that referenced this issue Oct 21, 2022
* Use @xilopaint’s fork of @deanishe’s Workflow module
    - See deanishe/alfred-workflow#97 for details
* Format using black
* Add shebang & call script directly
@xilopaint
Copy link

@xilopaint Thanks for the wonderful port to Python3.. I have now moved three of my workflows to Python3 using your port!

AAdvantage EShopping SmartThings UniFi

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 from: workflow.py:2131 results.sort(reverse=ascending) to: workflow.py:2131 results.sort(key=lambda x: x[0], reverse=ascending)

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.

https://stackoverflow.com/questions/55695479/typeerror-not-supported-between-instances-of-dict-and-dict

@schwark It's fixed. Thanks for pointing it out.

@ischaojie
Copy link

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.

@0xdevalias
Copy link

0xdevalias commented Dec 19, 2023

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

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

Originally posted by @NorthIsUp in #97 (comment)


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#2 for more.

Originally posted by @tomy0000000 in #97 (comment)

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.

Originally posted by @tomy0000000 in #97 (comment)


@NorthIsUp - I've run into a bunch of potentially special uses cases where I found the Py3 fork isn't really working well:

  • Auto-update support
  • Background support (not working correctly)

That being said -> considering lack of input from @deanishe - I'm at a bit of a loss with what he wants to do with this library...

I have fixed these issues and others. I think I have a fully functional library at this moment with a cleaner codebase. @vitorgalvao, moderator of Alfred Forum, suggested me to take over the library as a community-approved successor. But I'm still waiting for @deanishe's decision about the future of the lib.

@NorthIsUp, whose work was partly adopted in my private project, can be defined as a collaborator of the repo with privileges to commit changes unless he prefers to start his own repo.

In any case I'm still waiting for @deanishe to share his perspective. An official update is still the best option.

Originally posted by @xilopaint in #97 (comment)

@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 workflow folder from the repository of my Alfred PDF Tools workflow. I still have some work to make the codebase compliant with Pylint but this part is almost done. It's already compliant with Black and Bandit.

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.

Originally posted by @xilopaint in #97 (comment)

@xilopaint whed do you plan to publish py3 fork?

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

Originally posted by @xilopaint in #97 (comment)

Summary of Forks

So to summarise all of the above forks:

See also:

@NorthIsUp
Copy link

pull requests welcome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests