rice.shawn

Do you want to have versioned libraries and utilities live side-by-side? Do you want to make your workflows smaller but keep or expand the functionality with helper apps? Do you want to make sure that everything works regardless of whether Gatekeeper is active on other users' computers? Then you might consider implementing the Alfred Bundler* dependency framework in your workflows.
 
To use it, all you have to do is include a small file in your workflow and make, usually, one call per utility/library you want to use, and, that's it. The bundler will automatically download any utility that you attempt to use that the user doesn't have installed, and, what's even better, is that it will keep everything in the Alfred 2 data directory instead a workflow directory or a user's Applications directory.
 
If you want to see a _very_ basic implementation, then download an example workflow from Packal and open it up to see the workflow's anatomy.
 
The libraries / utilities mentioned below are just pre-defined assets that you can load with no additional work. You can actually use this framework for any asset** by including a small JSON file with your workflow.
 
Take a look at the documentation page on Github for more information.
 
* The bundler is intentionally poorly named because it makes it so that you don't have to bundle dependencies.
** Don't try this with python or ruby libraries/modules/gems yet. A future version of the framework might support those languages, but, for now the idiosyncratic nature of package management with those languages makes this sort of approach difficult.
 
---
 
So, for a variety of reasons, I wrote a framework to use with Alfred to manage dependencies for some types of libraries as well as commonly used "utilities" like terminal notifier.
 
I'll push the release shortly, but I want to make sure that I include some good defaults with the initial version.
 
Right now, I've included:
 
PHP
Workflows.php (v0.3.3) CFPropertyList (v2.0) Bash
BashWorkflowHandler Utilities
SetupIconsForTheme GlyphManager Terminal-Notifier (v1.5.0) CocoaDialog v3.0.0-beta7 v2.1.1 Pashua PHP5.5.5-CLI Viewer (an automator application that shows a pop-up HUD) I can't include Python or Ruby libraries (modules/gems) yet because they work entirely differently and call for a much more complex and intense setup. But, are there any other utilities or libraries that I should include?
 
Let me know, and when you do, post a link.

Quite a few people have asked for the ability to execute workflows at certain times. Well, here's (kind of) a solution.
 
Alfred Cron (note: consider this workflow to be a 'beta' right now) with will run any bash command on any interval that you define. Now, this means that you can run any script of any kind (to run a python script, you'd just write: python "/path/to/script.py" 'args'). It also means that you can take advantage of the new External Triggers in Alfred. So, if you want to run a workflow in the background at a certain time, then you can as long as there is an External Trigger for that workflow.
 
Fun idea: if you're decently good at scripting, then you can replace Hazel with this workflow.
 
You can define cron jobs through a nifty little GUI box. Just, see it in action in the GIF below:

 
More detailed documentation is available at http://shawnrice.github.io/alfred-cron.
 
Download it from Packal.
 
Note: Alfred Cron uses the Alfred Bundler framework, so when you first execute the workflow, it will take a moment to install the bundler, Pashua, BashWorkflowHandler, and Terminal Notifier. So, be patient at first. They need to download only once.
 
Also, Alfred Cron makes use of Ctwise's brilliant SetupIconsForTheme, so the workflow will adjust to your Alfred whether it is light or dark.

I think that it's one of those things that has the potential to change how we use Alfred in a radical way. Although, I don't know what that is yet (hence, I started this topic).
 
I know that it provides a way for Workflows to interact with each other, if we stay solely in the context of Alfred.
 
With Hazel, you could automate mundane tasks that work with Alfred. And, whenever we use Hazel, we could use that new cron workflow for things. So, say if Stephen wanted his Zotquery workflow to have it's sqlite database clone up to date with Zotero's, he could add an external trigger to the "update cache" argument and then call it, say, once an hour or once a day via Alfred Cron. Carlos' Evernote workflow could start interacting with (again) Stephen's Evernote Wiki workflow in that if something is added to one, then it queues something else up in another.
 
These aren't particularly outside-the-box ideas, but I'm confident that others are there.
 
I guess that it also paves the way for something more like a "workflow" suite in which you could create several workflows that are related to each other and can function on their own but then can extend each other as well. But, again, I can't think of anything particularly brilliant to create here.
 
I could imagine that if I put an external trigger on my "caffeinate" workflow, then other workflows could turn caffeinate on if they're in the middle of a longer process and then turn it off when they're done (although, I'd recommend that they check to see if it was on first, and, if so, how long, and then make sure that the timer is restored afterward). So, with that, I should probably extend that workflow to accept the parameter to "keep awake until a certain process is done" so that people can plugin into it with their own process.
 
I might be able to extend WHW so that people could tap into it with their own help commands or something. (BTW, I'm still rewriting it and am currently stuck on UI issues, mostly in regards to navigation when someone has, say, 100 workflows installed — certainly not me! — but it support help files for single workflows, and I want to make it so that workflows can provide their own help file that will override WHW's standard output.)
 
I do think that it would be good practice for us to put in external triggers on most of the "run script" workflow objects for now just in case other people could make use of them even if we don't have any ideas how. So, maybe that makes it so that we consider all of our scripts to be not just "workflows" but also (potentially) useful APIs for workflows.

Quite a few people have asked for the ability to execute workflows at certain times. Well, here's (kind of) a solution.
 
Alfred Cron (note: consider this workflow to be a 'beta' right now) with will run any bash command on any interval that you define. Now, this means that you can run any script of any kind (to run a python script, you'd just write: python "/path/to/script.py" 'args'). It also means that you can take advantage of the new External Triggers in Alfred. So, if you want to run a workflow in the background at a certain time, then you can as long as there is an External Trigger for that workflow.
 
Fun idea: if you're decently good at scripting, then you can replace Hazel with this workflow.
 
You can define cron jobs through a nifty little GUI box. Just, see it in action in the GIF below:

 
More detailed documentation is available at http://shawnrice.github.io/alfred-cron.
 
Download it from Packal.
 
Note: Alfred Cron uses the Alfred Bundler framework, so when you first execute the workflow, it will take a moment to install the bundler, Pashua, BashWorkflowHandler, and Terminal Notifier. So, be patient at first. They need to download only once.
 
Also, Alfred Cron makes use of Ctwise's brilliant SetupIconsForTheme, so the workflow will adjust to your Alfred whether it is light or dark.

You need to add in 
the quoted form of so that the path will be escaped.
 
So something like
tell the last session write text "cd " & the quoted form of q & "; clear; pwd" end tell should work.

Another problem based on that shell is how the .git directories are read. I ran into this problem with the workflow processing script on Packal. It was written in PHP, but it just invoked the git commands via shell commands, so here is the relevant github code:
// Add all the files $command = "git --git-dir $github/.git --work-tree $github/ add $github/*"; exec($command); // Commit changes $command = "git --git-dir=$github/.git --work-tree $github/ commit -am 'updated for $bundle version: $version'"; exec($command); // Push it to the repo $command = "git --git-dir=$github/.git --work-tree $github/ push origin"; exec($command); Obviously, you don't have those variables. The "$github" variable is just the full path to the local git repo.

I'm happy to announce that after months of development, I'm ready to make a new workflow and theme repository available to the public as an open beta: Packal. Workflows and themes are taggable and searchable. You can add in the icons, screenshots, long descriptions, and brief ones. There are many different ways to find whatever you need there. Since this is an initial announcement, there isn't much content there yet, except for the workflows and themes that a few kind testers uploaded.
 
Themes are stored as a simple application URL, which means there are no files to download, but, instead, they import directly into Alfred2. Workflows are scanned for viruses after they are submitted but before they are made available publicly. Workflow authors can easily update their workflows just by editing the page and replacing the workflow file there.
 
What is even better is that Packal has its own updater for workflows. So, you have the option to update any workflows that you have downloaded from Packal.
 
I think that these are exciting developments for Alfred, and this sort of repository is what many people have been waiting for since these forums were created.
 
One great advantage for distributing your workflows via Packal is that you do not need to maintain your own download links for your workflows anymore, so you won't need to worry about download limits on sharing services. Another advantage is that it will receive more visibility as it is a place where people can look for workflows and themes without having to page through the impressive number of posts in these forums.
 
So, please, head over to Packal, browse what's there, and, very importantly, submit your own workflows and themes.
 
--Shawn

It seems that there are no other suggestions, so here is the link to the bundler. With some testing besides myself (thanks Dean and Tyler), it seems to work. View the documentation on how to implement it.

Do you want to have versioned libraries and utilities live side-by-side? Do you want to make your workflows smaller but keep or expand the functionality with helper apps? Do you want to make sure that everything works regardless of whether Gatekeeper is active on other users' computers? Then you might consider implementing the Alfred Bundler* dependency framework in your workflows.
 
To use it, all you have to do is include a small file in your workflow and make, usually, one call per utility/library you want to use, and, that's it. The bundler will automatically download any utility that you attempt to use that the user doesn't have installed, and, what's even better, is that it will keep everything in the Alfred 2 data directory instead a workflow directory or a user's Applications directory.
 
If you want to see a _very_ basic implementation, then download an example workflow from Packal and open it up to see the workflow's anatomy.
 
The libraries / utilities mentioned below are just pre-defined assets that you can load with no additional work. You can actually use this framework for any asset** by including a small JSON file with your workflow.
 
Take a look at the documentation page on Github for more information.
 
* The bundler is intentionally poorly named because it makes it so that you don't have to bundle dependencies.
** Don't try this with python or ruby libraries/modules/gems yet. A future version of the framework might support those languages, but, for now the idiosyncratic nature of package management with those languages makes this sort of approach difficult.
 
---
 
So, for a variety of reasons, I wrote a framework to use with Alfred to manage dependencies for some types of libraries as well as commonly used "utilities" like terminal notifier.
 
I'll push the release shortly, but I want to make sure that I include some good defaults with the initial version.
 
Right now, I've included:
 
PHP
Workflows.php (v0.3.3) CFPropertyList (v2.0) Bash
BashWorkflowHandler Utilities
SetupIconsForTheme GlyphManager Terminal-Notifier (v1.5.0) CocoaDialog v3.0.0-beta7 v2.1.1 Pashua PHP5.5.5-CLI Viewer (an automator application that shows a pop-up HUD) I can't include Python or Ruby libraries (modules/gems) yet because they work entirely differently and call for a much more complex and intense setup. But, are there any other utilities or libraries that I should include?
 
Let me know, and when you do, post a link.

exec("$cmd"); won't open a terminal window but will do it in the background.
 
The open command should, but you might need the full path $cmd = "open -a /Applications/iTerm.app"; exec($cmd);
 
You can't tell iTerm to switch to that directory from inside PHP. You need to use Applescript to send that command to iTerm once it has been opened. Actually, just do the opening and everything else in Applescript. It's easier. You can launch an Applescript from inside PHP with the bash command osascript.
 
Bash:
You have smart quotes. Bash won't like those. Why not just use: echo "{query}" if in an alfred window? If you want to open a directory in bash from the query, then just use `$query` if it has the full path in it. Otherwise, you might need to do `cd "$query"`. Note the non-smart double-quotes so that the variable will expand.

It really is an ugly icon though. I should take some time and try to design a much better one. Unless someone wants to do me the favor (any good graphic designers reading this?)...

2015-09-17: Major update to version 2

Alfred AppScripts Workflow

List, search and run/open AppleScripts for the active application.



Download

The workflow can be downloaded from GitHub or Packal.

The source code is also available on GitHub.

Usage
.as [<query>] — Show/search list of AppleScripts for the active application ↩ — Run the selected script. ⌘+↩ — Open the selected script in Script Editor. ⌥+↩ — Reveal the selected script in Finder. appscripts [<query>] — Show workflow configuration. Help – Open this file in your browser. (No) Update Available — Whether or not the workflow can be updated. Action the item to update or force an update check. Search Directories Recursively – Whether the script directories should be searched recursively. Use with some caution. Edit Script Directories — Open the configuration file in your default editor. The file contains a detailed description of how it works. Reset to Defaults — Delete configuration and cache files. Where are these scripts?

The workflow comes with a default set of directories. These are defined in a settings file that you can edit yourself. Use the Edit Script Directories option in the configuration (keyword appscripts) to open the file in your editor.

These are the default directories. {app_name} will be replaced with the name of the currently active application, e.g. BBEdit or OmniFocus, and {bundle_id} with the application's bundle ID, e.g. com.barebones.bbedit or com.omnigroup.OmniFocus2:
~/Library/Scripts/Applications/{app_name} ~/Library/Scripts/Applications/{bundle_id} ~/Library/Application Scripts/{app_name} ~/Library/Application Scripts/{bundle_id} ~/Library/Application Support/{app_name}/Scripts ~/Library/Application Support/{bundle_id}/Scripts ~/Library/Containers/{bundle_id}/Data/Library/Application Support/{app_name}/Scripts Any .scpt, .applescript or *.scptd (script bundle) files found within the above directories will be shown.

If you add a directory path that doesn't contain {app_name} or {bundle_id}, it will match every application and the scripts will always be shown. See the settings file (AppScript Directories.txt) for more information.

Licence, thanks

The workflow code and the bundled Alfred-Workflow and docopt libraries are all licensed under the MIT Licence.

The workflow icon was kindly donated by @Jono.

CarlosSZ has written an amazing Evernote workflow. You can find it here: http://www.packal.org/workflow/evernote. Or on this thread. There's another one to manage an Evernote wiki that you can find here: http://www.packal.org/workflow/en-wikify. Or on this thread.

Need a quick place to write up some text that you won't need to save? Need a slightly more persistent clipboard? Don't want to bother opening up a text editor? Already have your browser open?
 
Download Chrome Notepad from Packal.
 
Just type "cn"; and you'll see a new tab open in Chrome that will give you a styled scratchpad.
 
Right now it's only Chrome (I wrote this quickly for myself not in the most efficient way), but it can be expanded to other browsers.
 
 

CarlosSZ has written an amazing Evernote workflow. You can find it here: http://www.packal.org/workflow/evernote. Or on this thread. There's another one to manage an Evernote wiki that you can find here: http://www.packal.org/workflow/en-wikify. Or on this thread.

Script filter 1 is just an easy way to output multiple lines in bash. So, it's regular XML with the format and the fields necessary for Alfred to read. The "cat" means read, and the <<< CODE [...] CODE delimits the string to read to the buffer (to Alfred).
 
--- demo 1
 
-f means file exists.
 
Alfred starts executing code in the workflow directory. Since this is just a demo, David was saving these to a text file in the workflow directory itself. If you were to implement this sort of thing, then you'd want to save the temp file to the caches directory.
 
tr translates/deletes characters ( see the man pages on tr ). The ${} structure in bash is string manipulation, so it's running the commands and outputting them into the "in" variable. "\" is an escape character, so if you want to search for a "\" you have to escape it; hence \\. So, the string takes the query and deletes and "\" from it, saving it into the variable "in".
 
Then the contents of "in" are saved into the "saved.txt" file.
 
--- demo 2
Takes the saved information in saved.txt and pulls it into a "data" variable.
 
echoing "$data {query}" combines the previous query (saved in saved.txt) and combines it with the current query.
 
---
 
The overall idea is that you can't get more than one argument out of a script filter, so this is a fun little hack in which you save previous queries in a temp file and read them into the query again to make it work as a "new" query that uses the same script filter but with a nice little delimiter so that you can see the progression, a little like breadcrumbs.

I'm happy to announce that after months of development, I'm ready to make a new workflow and theme repository available to the public as an open beta: Packal. Workflows and themes are taggable and searchable. You can add in the icons, screenshots, long descriptions, and brief ones. There are many different ways to find whatever you need there. Since this is an initial announcement, there isn't much content there yet, except for the workflows and themes that a few kind testers uploaded.
 
Themes are stored as a simple application URL, which means there are no files to download, but, instead, they import directly into Alfred2. Workflows are scanned for viruses after they are submitted but before they are made available publicly. Workflow authors can easily update their workflows just by editing the page and replacing the workflow file there.
 
What is even better is that Packal has its own updater for workflows. So, you have the option to update any workflows that you have downloaded from Packal.
 
I think that these are exciting developments for Alfred, and this sort of repository is what many people have been waiting for since these forums were created.
 
One great advantage for distributing your workflows via Packal is that you do not need to maintain your own download links for your workflows anymore, so you won't need to worry about download limits on sharing services. Another advantage is that it will receive more visibility as it is a place where people can look for workflows and themes without having to page through the impressive number of posts in these forums.
 
So, please, head over to Packal, browse what's there, and, very importantly, submit your own workflows and themes.
 
--Shawn

Glad you like the idea. I haven't completely forgotten about this project, but currently, for my Alfred projects, it's behind one major one that should be released soon.
 
Version 1 of WHW was a great idea, but it does suffer from usability concerns, and these were in part due to the way that I decided to generate the help files. I've since figured out much, much better ways to go about it, and I have some of the framework done for a better version.
 
The next version won't use quicklook (well, I might have that as an option but not the default); instead, it'll use a custom viewer as default with other options of opening the file in a browser window and generating it as a PDF and opening it in Preview. Instead of generating markdown files, it'll instead generate richer HTML pages with quite a bit of javascript that should make navigation and layout much better. It'll have the option to just view one workflow as well as all of them. The plist parsing will be done quite a bit better for more accurate results. It will also allow workflows to define their own help files for richer content. If the help file exists in the workflow folder, then it will use that, and it will fall back on plist parsing. The workflow will also include an easy help generator for workflow authors so that they don't need to write out xml/json/plist files by hand. Lastly, it'll have a nice speed increase by "caching" the help files and regenerating them only when it senses that a workflow could have changed.
 
I don't have an exact timeline to finish it, but it should be pretty sweet when the new version sees the light of day.
 
Shawn

Vítor is, as usual, spot on here. As for the security, it does help that Apple locks down quite a few commands with the need for an administrator password. The workflows are, basically, unsigned software freely distributed, and so they carry the risks of any unsigned software freely distributed. If you grab anything off Packal, then the workflow has been run through a virus scan, but that accounts only for a tiny bit of the security risk. However, we've built up a bit of a community on these forums, and Packal piggybacks off of that. If actual malicious code is spotted in a workflow — which to my knowledge has yet to happen — I'm sure that we'll catch it and throw up all sorts of warning signs. If I'm notified of any malicious workflow that appears on Packal, rest assured that it will be taken out of circulation immediately. Also, organically, we've also come up with a set of best practices for workflow development that values transparency and security. It is discouraged to install anything on anyone's computer without letting them know, and it's always best to try to keep everything contained to the appropriate data and caches directories. Ultimately, the security in these workflows is built around a level of trust in this community. So far, it seems to have worked out fairly well.

You have the single/double quotes backward on this line:
        $cmd = 'open -a Finder "$data_dir"'; You probably need a semi-colon on this line: $data_subdir = basename( $data_subdir ).PHP_EOL Depending on what is being returned, you might need equivalence (==) rather than equality (===) on this line:
if ( $data_subdir === $bundle_id ) You need to use the "{query}" variable from Alfred not the "$query" variable on this line: $plist_dir = $query . "/info.plist"; The following line isn't the data directory. $data_dir = $w->home() . '/Library/Application\ Support/Alfred\ 2/Workflow\ Data'; If you want to grab all the data directories for Alfred Workflows, then you could just make it easier: $data_dirs = scandir($w->data() . "../"); It also might be easier/more reliable to get the bundle id from each plist by doing: $cmd =" /usr/libexec/PlistBuddy  -c 'Print :bundleid' '$data_dir/info.plist'"; $bundle = exec($cmd);   I'm assuming that you want to grab all of the files out a some matching workflow's data directory. If you just want to grab all the files out of the current workflow's workflow directory, then you just need to do: $files = scandir(".");

Re: #1 — Not yet. Packal is collecting download statistics, but I haven't written a way for workflow authors to see them. That is on the todo list. Also, the Packal workflow has a "reporting" mechanism (which can easily be turned off) to send workflow information back to the Packal server. Basically, it sends a report approximately 1/week about which workflows are installed and which of those are enabled/disabled. I figure that information could be great for workflow developers to have. That functionality is mostly written, so it should be included in the initial release.
 
Re: #2 — Not yet, but good idea. I'll put that on the todo list and let everyone know when it's there.
 
One new thing about Packal, though: when you release a workflow, you can now specify a Github Repo if you use one, and the workflow page will link to the repo.

It is weird, but it's so ingrained that it's hard to remove. It's like names: I live in NYC and everyone knows where the Triboro bridge is, except that it doesn't exist anymore because it was renamed the Robert F Kennedy Bridge six years ago. When I mentioned this to New Yorkers, they have no idea and will still refer to it as the Triboro bridge.
 
The main upshot about DST is that it helps move regular business hours in line with seasonal light levels, which does have an effect that it conserves some energy usage. The other great thing is that once a year, the bars get to stay open an extra hour in the US. It's always a magical weekend. Everything else about it sucks.
 
Anyway, adding accounting information for DST might be fairly hard in bash, but I do know that PHP has some great built-in functions to detect DST. A fix might be to use PHP to check for DST and adjust accordingly. The drawback is that it will make the workflow's performance suffer a bit.

I used the Github as the storage backend for a few main reasons: (1) to offload some of the stress from the Packal server for the upgrade workflow (which is way overdue — my bad), and (2) to have a redundant backup for current files as well as a revision history. Packal itself has the revision history embedded into it, and some rollback features for the workflow authors. (3) I've seen repos come and go. I'm planning on keeping Packal up for as long as Alfred exists, but, if for some reason it disappears, all of the important data will still be there for someone else to take over (although I do hope that no one does this anytime soon because I've put so much work into Packal and maintain it out of my own pocket). So, Vitor is mostly correct when it comes to convenience.
 
Alleyoop was great, but it was truly buggy because of the problems that Dean mentioned with the user-generated JSON, and it also needed to make so many calls to query the workflows because each was stored in a different place. Having everything centrally will speed up that performance nicely. Alleyoop was great, but Daniel, who wrote it, always looked at it as a stopgap. Actually, I approached Daniel about setting up Packal early on, and we had some great conversations about it, but other life commitments took him away from the project.
 
I also designed it because the need for the context with the workflows. Alfredworkflows.com suffered from this lack of context for workflows. The long list was great, but it was inherently limited.
 
Since Packal, and any sort of repository, is only as good as its user-contributed content, I want to make it as easy for workflow authors to keep their work updated. It is an extra step for everyone, but I do think that it does have many benefits for Alfred users and workflow/theme creators. I still have a lot of work to do on the site to make things easier for workflow authors especially, and the only thing keeping those from being my first-priority is a lack of time from other exigencies in life.
 
But do keep expecting to see improvements on it.

Tyler is right. These are exactly the things that are fairly easy to do with a bit of programming knowledge and the Powerpack. Actually, all you would need to do is leverage mdfind in a script filter specifically aimed at ".groovy" files. There are similar workflows that already exist and could be modified.
 
If you want to see the sort of things that are possible with the Powerpack, then browse through the "Share Your Workflows" forum, or head to www.packal.org, and take a look around at the workflows that are available there to download. Granted, you need the Powerpack to use any of these.

The Alp library has some keychain integration, if I remember correctly. So if you're good with python, look into that one.