search

deanishe / alfred-workflow

Full-featured library for writing Alfred 3 & 4 workflows
https://www.deanishe.net/alfred-workflow/
Other
2.98k stars 234 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.

jeeftor commented 2 years ago

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

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

NorthIsUp commented 2 years ago

Pull requests accepted!

I think we are all deeply appreciative @deanishe's work, and also of their time. Nobody has a responsibility to forever maintain their projects. Sometimes it is up to the community to pick up the work and carry it forward. I consider my python3 work a hard fork. So if you have any questions or contributions please take them over to NorthIsUp/alfred-workflow-py3 On Apr 4, 2022, 2:07 PM -0700, Jeef @.***>, wrote:

@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... — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

jeeftor commented 2 years ago

!! Works for me @NorthIsUp!!

jeeftor commented 2 years ago

@NorthIsUp - is there any value in breaking the fork so we can get an issue tracker for your version?

xilopaint commented 2 years ago

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

NorthIsUp commented 2 years ago

Issues enabled! On Apr 4, 2022, 14:22 -0700, Jeef @.***>, wrote:

@NorthIsUp - is there any value in breaking the fork so we can get an issue tracker for your version? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

glyph commented 2 years ago

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

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

@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 commented 2 years ago

@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 commented 2 years ago

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

esseti commented 2 years ago

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

tomy0000000 commented 2 years ago

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

@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 commented 2 years ago

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

YuHoYe commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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

xilopaint commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

@xilopaint whed do you plan to publish py3 fork?

jeeftor commented 2 years ago

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.

jeeftor commented 2 years ago

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.

tomy0000000 commented 2 years ago

@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 commented 2 years ago

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

xilopaint commented 2 years ago

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

xilopaint commented 1 year ago

@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 commented 1 year ago

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 commented 10 months ago

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 https://github.com/deanishe/alfred-workflow/issues/97#issuecomment-751307022

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.

Originally posted by @tomy0000000 in https://github.com/deanishe/alfred-workflow/issues/97#issuecomment-1070962158

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 https://github.com/deanishe/alfred-workflow/issues/97#issuecomment-1073668304

@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 https://github.com/deanishe/alfred-workflow/issues/97#issuecomment-1088032242

@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 https://github.com/deanishe/alfred-workflow/issues/97#issuecomment-1120290043

@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 https://github.com/deanishe/alfred-workflow/issues/97#issuecomment-1279937319

Summary of Forks

So to summarise all of the above forks:

See also:

NorthIsUp commented 7 months ago

pull requests welcome!