Jump to content

Recommended Posts

Alfred-Workflow installs with pip for python3, but on usage it calls modules that don't exist in python3. Is there a way around this, or do scripts need to be run with python 2? Will this change in the future? 

 

Very new to this, trying to setup my own simple workflow.

Edited by therockmandolinist

Share this post


Link to post

Alfred-Workflow doesn't support Python 3. It says on the Cheeseshop page that 2.6 and 2.7 are the only supported versions, so I'm not sure why pip thinks it's okay to install it in Python 3.

 

There's almost zero chance that I'll add (official) Python 3 support to AW until 2 things happen:

  1. Alfred v3 comes out. Alfred 2 runs workflows in an incorrectly-configured environment that makes it impossible for me to write a version of Alfred-Workflow that works out of the box with Python 3. Andrew has said that he won't be changing the environment in version 2 of Alfred, as it may change the way existing workflows work.
  2. Apple starts shipping Py3 with OS X.

There's no compelling reason not to add Py3 support (no. 1 is easy enough to work around), but the bottom line is, AW is my project and I just don't like Python 3 very much. I have very little desire to invest a lot of my time in what I consider messing up AW's code in order to support a language I neither like nor use, and which doesn't (yet) provide any must-have features versus Python 2.7.

 

So, yeah, if you want to use AW, you'll have to use Python 2 for the foreseeable future.

 

And unless there's some compelling reason to use Python 3, using Python 2 has the additional advantage that you can share your workflows between machines, or with other users, and they will work without needing to install Python 3.

Edited by deanishe

Share this post


Link to post

Re-reading my previous comment, I think I should say—in fairness to Python 3—that workflows are a lot easier to write in Python 3 than Python 2. Provided you set the locale to something UTF-8, you mostly won't have to worry about encoding and decoding any strings (which is a PITA in Py2 and the cause of a very large proportion of bugs).
 
AW takes care of a lot of that for you, but it's still something you usually have to deal with in Python 2.

Edited by deanishe

Share this post


Link to post

Nothing material has changed.

 

Until Apple starts shipping Python 3 with macOS, I personally won't consider adding Py3 support. If someone else wants to do it and submit a pull request, that's a different matter.

 

There are two related reasons for that: Firstly, it's a lot of work just to end up with a library that works exactly the same as it did before. Secondly, the net result of Py3 support would be to increase developer convenience (no more UnicodeDecodeError) but at significant cost to users (Py3 workflows can't run out-of-the-box on a vanilla macOS—users must first get their hands dirty installing developer tools).

 

That is antithetical to the way I approach workflow development. When faced with the choice of using a preferred language/tool that isn't pre-installed or using one I don't know or don't like that is pre-installed, I have always chosen the latter. Developers having to mess around with development tools they don't like is (almost) always preferable to workflow users having to mess around with development tools at all.

 

That's not just a philosophical position. Look in the threads belonging to Node-based workflows and they're full of users asking for help with getting the damn things running. I don't really want to be the guy who turns Python workflow development into a similar tragicomedy.

 

All that said, I imagine Apple's next OS will have Python 3 and the above becomes largely moot.

Share this post


Link to post
On 3/30/2019 at 11:38 AM, deanishe said:

That's not just a philosophical position. Look in the threads belonging to Node-based workflows and they're full of users asking for help with getting the damn things running. I don't really want to be the guy who turns Python workflow development into a similar tragicomedy.

 

I refuse to install any Node-based workflow for the sole reason they are not installed in the default workflow's installation folder.

Share this post


Link to post
5 hours ago, xilopaint said:

they are not installed in the default workflow's installation folder.

 

In addition to that (which means they don't sync like proper workflows), updating via npm is broken. Apart from the bug they've been sitting on for nearly a year now, by not using Alfred to install updates, all your customisations (hotkeys, keywords) get dropped on the floor.

 

The way the community around alfy (and some other Node devs) generally go about workflow development is fundamentally broken, imo. By that, I mean it's impossible to create an Alfred workflow that Just Works the way they're intended to.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...