Workflow Library for Python

[dfay]

Is there any particular file or phrase we can search for to see if the update is necessary in any of our workflows?

[deanishe]

What? Like grep for?

 

update_settings and run_in_background are your huckleberries:

grep -R update_settings . | grep -v /workflow/
grep -R run_in_background . | grep -v /workflow/

That should filter out the library itself. Hopefully, @vitor will show up with some of his CLI wizardry to expand that to return the folders the library wants installing in  

[xilopaint]

1 hour ago, deanishe said:

Released v1.25 with an extremely important bugfix for Sierra. Please see the notice at the top of the OP for details.

 

I've also added a new feature: session IDs and session-scoped caching. A session ID is valid as long as the user is using your workflow. If they switch to a different workflow or close Alfred, the session ID is reset.

 

The Workflow3.cache_data() and Workflow3.cached_data() have a new session argument. If session is set to True, the cache will magically ^[1] expire when the user stops using your workflow or Alfred.

 

It's awesome for data like a list of tabs/windows for Application X. They're slow to fetch, but you don't know how long you can cache them for, as they're liable to change shortly after your workflow runs (or as a direct result thereof).

 

1. It's currently not very magical at all. It works by prefixing the cache filename with the session ID, so it fills your cache with lots of files. There is a Workflow3.clear_session_cache() method, but that's currently very dumb and deletes all session-scoped data. I'll add some smarter cleanup code once I figure out where the best place to put it is (hopefully, so you won't have to run it manually).

 

Can this release address this issue with Sublime Text Projects workflow?

[dfay]

2 hours ago, deanishe said:

What? Like grep for?

 

update_settings and run_in_background are your huckleberries:

grep -R update_settings . | grep -v /workflow/
grep -R run_in_background . | grep -v /workflow/

That should filter out the library itself. Hopefully, @vitor will show up with some of his CLI wizardry to expand that to return the folders the library wants installing in  

 

Thanks 

 

That found update_settings in 

• Search OmniFocus http://www.packal.org/workflow/search-omnifocus
• Date Calculator http://www.packal.org/workflow/date-calculator
• Ulysses http://www.packal.org/workflow/ulysses

But none of mine (b/c I'm too lazy to set up updating )

 

But we should also be checking the library version for any of our own (and presumably any which the devs don't update too), correct?

[dfay]

(this would be so much more pleasant if we could get human-readable names for the workflow directories....)

[deanishe]

6 hours ago, xilopaint said:

 

Can this release address this issue with Sublime Text Projects workflow?

 

Yes.

 

I'm in the process of updating my workflows and releasing new versions.

[deanishe]

TEMPORARY FIX

 

Grab this workflow and follow the instructions on how to use it.

 

It will replace buggy versions of Alfred-Workflow with a working one in any workflows you have installed.

 

Vítor posted a handy script that can fix all your workflows at once.

 

If you're not a big shell user, here's another way:

1. Download the latest release of Alfred-Workflow
2. Extract the zip file
3. In Alfred Preferences, right-click on the broken workflow and choose Open in Finder
4. Replace the workflow directory in the broken workflow with the one from the Alfred-Workflow release you downloaded
5. Repeat for any other workflows causing the same issue

This will make the workflow fully-functional again.

Edited April 8, 2017 by deanishe
Replace manual instructions with link to Fixum workflow

[vitor]

9 hours ago, dfay said:

(this would be so much more pleasant if we could get human-readable names for the workflow directories....)

 

cd "{{WHATEVER YOUR WORKFLOWS DIRECTORY IS}}"

IFS=$'\n'

for d in *; do
  echo "$(/usr/libexec/PlistBuddy -c 'print name' "${d}/info.plist") ($(/usr/libexec/PlistBuddy -c 'print createdby' "${d}/info.plist")) → ${d}"
done

That will just output the names (and authors), not rename the directories. To rename, do instead:

cd "{{WHATEVER YOUR WORKFLOWS DIRECTORY IS}}"

IFS=$'\n'

for d in *; do
  workflow_name="$(/usr/libexec/PlistBuddy -c 'print name' "${d}/info.plist")"
  mv "${d}" "${workflow_name}.$RANDOM"
done

The .$RANDOM at the end adds a random integer to mitigate name collisions. As far as I know, Alfred doesn’t really care what the directories are called.

 

Note I don’t recall if `PlistBuddy` comes by default with macOS or is installed with Xcode’s CLI tools, so you should check first if it exists.

[xilopaint]

14 hours ago, deanishe said:

TEMPORARY FIX

 

Vítor posted a handy script that can fix all your workflows at once.

 

My performance was heavily affected for a long time for this issue. Maybe the issue and this script solution could get more attention in a specific warning thread. Don't get me wrong but this is big.

Edited April 3, 2017 by xilopaint

[mikedvzo]

I tried the following fix but still having issues:

 

#!/bin/bash
cd "/Users/xxxxx/Dropbox/Sync/Alfred 3/Alfred.alfredpreferences/workflows"

IFS=$'\n'

for d in *; do
  workflow_name="$(/usr/libexec/PlistBuddy -c 'print name' "${d}/info.plist")"
  mv "${d}" "${workflow_name}.$RANDOM"
done

[Weaselboy]

6 hours ago, deanishe said:

TEMPORARY FIX

 

This will make the workflow fully-functional again.

 

Thanks! This worked for me on the Pocket workflow that was broken.

[deanishe]

1 hour ago, mikedvzo said:

I tried the following fix but still having issues:

 

#!/bin/bash
cd "/Users/xxxxx/Dropbox/Sync/Alfred 3/Alfred.alfredpreferences/workflows"

IFS=$'\n'

for d in *; do
  workflow_name="$(/usr/libexec/PlistBuddy -c 'print name' "${d}/info.plist")"
  mv "${d}" "${workflow_name}.$RANDOM"
done

 

Renaming the workflow directories doesn't fix anything. It just makes it easier to see which workflow is in which folder (as Alfred gives them meaningless names by default).

Edited April 3, 2017 by deanishe

[deanishe]

Please see this thread for an easy, temporary fix for users till devs can push new versions of their workflows.

[deanishe]

4 hours ago, xilopaint said:

My performance was heavily affected for a long time for this issue. Maybe the issue and this script solution could get more attention in a specific warning thread. Don't get me wrong but this is big.

 

I've stickied a thread at the top of the forum now that I have a user-friendly fix available. (@vitor's script relied on pip, which is every bit as difficult to work with as he says).

 

And yeah, it is pretty big. It's broken an awful lot of people's stuff  

 

Touch wood, a fix is in, and the workflow I posted should at least fix users' workflows, although developers will still have a lot to do.

 

In my defence, I've been using the offending section of code for literally over a decade. It has always worked flawlessly on Linux and OSX. Until Sierra.

 

EDIT: Haha! I found it. This is where I got the code from about 14 years ago.

Edited April 3, 2017 by deanishe

[deanishe]

Released v1.26, which adds the ability to set workflow variables from Run Script actions in addition to Script Filters.

[xilopaint]

I haven't managed to set modifier keys using the Item3.add_modifier() method for Alfred 3. Is there a sample somewhere?

[deanishe]

In the documentation.

[xilopaint]

Thank you! I searched the documentation for a link dedicated to the modifier keys and once I didn't find I assumed there were none. Would it be a good idea adding one?

Edited May 5, 2017 by xilopaint

[deanishe]

16 minutes ago, xilopaint said:

I searched the documentation

 

Try the search function. It's on every page.

Edited May 5, 2017 by deanishe

[xilopaint]

add_modifier is a way better query. I tried modifier with no success. People aren't always smart doing searches.

[deanishe]

Yeah, the results for modifier are crap. OTOH, the search works well enough if you enter the name of the method you're interested in.

 

I'll look into cross-referencing the manual from the API documentation, as that would make the Dash docset much more useful.

[xilopaint]

Geez! I didn't know about the Dash docset!!! <3

[deanishe]

It's not very good, for the above-mentioned reason.

 

The Dash script for Sphinx docs only indexes the API docs, not the manual.

[xilopaint]

I need to create a keyword that will be invoked by the user in order to cache the entered argument (a stock symbol) for reusing in a script filter. Is there any easy way to achieve this with the library? I was looking into some methods like cache_data and store_data but I am not certain they can do the job.

[deanishe]

I'm not sure I really follow you.

 

You want the user to enter a currency symbol and save that for later use?

 

For something that simple, you should probably just use the settings API.

 

cache_data and store_data can easily do such a simple thing. In fact, they're probably overkill as they're designed for storing arbitrary data structures, not just simple strings.