Packal Updater

[rice.shawn]

Finally here: Update your workflows with the Packal Updater.

 

There is a longer explanation on the Packal page, so just check that one out, but I'll give you a short version here.

 

The updater will upgrade any workflows that you have downloaded from Packal when an upgrade becomes available. It cannot upgrade any workflows that you did not download from Packal.

 

When you launch it the first time, head over to the settings and configure how you want it to work. If you write workflows, then put in the name that you most often use. If you have a Packal account, put that name in there too. If you do those two things, then the updater won't try to upgrade your workflows. If there are workflows that you do not want to update if, say, you've modified them, then Blacklist them in the appropriate place, and the updater will ignore those workflows. 

 

If you're running Mavericks (or, theoretically, Yosemite), then you'll have access to a nifty little GUI. If you're not, then, well, you don't, but you can still configure and do everything from Alfred itself. See the animated screenshots below for a quick demo of both.

 

Three other notes:

 

(1) The Updater Workflow uses the Alfred Bundler, which has been receiving an overhaul. If you run into some trouble with it, then just go ahead and delete your bundler directory, and it will re-install itself. A newer version of the bundler should be coming out soon that will make some great fixes, but you needn't worry about that because the bundler will update itself.

 

(2) The Updater can send information to Packal about what workflows you have installed, enabled, and downloaded from Packal. It'll try to do this once a week if you do not disable the feature. It is anonymous reporting in that there is no way for me to figure out who you are from the data. Here's the command that I use to generate your unique identifier:

ioreg -rd1 -c IOPlatformExpertDevice | awk '/IOPlatformUUID/ { split($0, line, "\""); printf("%s\n", line[4]); }'

If you just plug that into a terminal, then you'll probably see something akin to:

 

.

 

(3) The Updater keeps backups of the workflows you've updated, so, if anything breaks, just open the backups folder and double-click the most recent version of the workflow to restore.

 

Anyway, go grab it from Packal, and start updating.

 

(And, as always, I think I've removed all the bugs, but, as I release this into the wild, I expect to find more. Just report them here.)

 

Lastly, the updater can update itself according to my tests. Cool, right?

 

Demo — Packal "GUI"

 

 

 

Demo — Packal Script Filter Interface

 

[MuppetGate]

Woohoo!!

[deanishe]

Deeply cool.

 

102 workflows Shawn? How the hell do you remember all the keywords?

 

EDIT:

 

Oh…

 

Edited July 2, 2014 by deanishe

[vitor]

I believe the sending of information should be off by default, or at the very least make it a mandatory choice to use the workflow. This is mainly on principle, though, as I certainly trust your intentions on this.

I’d also like the option to keep no backups of previous workflows. If something messes up, I’d rather go download it again, than having old versions linger in my Dropbox.

In addition, I’m finding something odd with this. This is more an issue with Alfred Bundler than with Packal Updater, but since you’re the author of both, and I’m seeing this with this workflow, I’m asking here. This workflow calls bundler and asks for permission to install terminal-notifier. I’ve denied permission, and yet terminal-notifier was still activated. I have no idea why, but this should clearly not happen. After that, it’s revealing itself to be a pest to remove. Even after removing alfred.bundler-aries and com.packal from both ~/Library/Caches/com.runningwithcrayons.Alfred-2/Workflow Data and ~/Library/Application Support/Alfred 2/Workflow Data, it still remains.
 
I’d also like an option to permanently deny Alfred Bundler — no means no. Currently, every action I try to do with this workflow calls it twice, just to install terminal-notifier, which it doesn’t need to do, since it is still being activated.

[rice.shawn]

There was a reason that I wrote the Workflow Help workflow to begin with...

 

 

Deeply cool.

 

102 workflows Shawn? How the hell do you remember all the keywords?

Edited July 2, 2014 by Shawn Rice

[paulw]

Thanks for this!

 

I can't get the GUI to work.

 

I believe the sending of information should be off by default, or at the very least make it a mandatory choice to use the workflow. This is mainly on principle, though, as I certainly trust your intentions on this.


I’d also like an option to permanently deny Alfred Bundler — no means no. Currently, every action I try to do with this workflow calls it twice, just to install terminal-notifier, which it doesn’t need to do, since it is still being activated.

 

I agree with these points.

[rice.shawn]

@Vitor : I think you hit the wrong "no means no," unless you meant the Canadian Punk band, which I'd never heard of before today.

 

Re: Workflow Reporting: I went back and forth on the workflow reporting between opt-in and opt-out. I ultimately went for the opt-out model and felt okay about it because I tried to become as transparent about it as possible both in how it works and how it will be used. Right now, it's just sending the JSON data to Packal while I'm writing the connector to display the data on Packal itself. After reading this, however, there might be a bit of a problem in that it will send a report before a user has a chance to turn it off. I'll make sure that I fix that in the next update (which will probably be done shortly).

 

Re: Backups: I thought that I had made that an option (these things have gone back and forth a bunch), but I'll make sure that you can disable backups in that version.

 

Re: Bundler issues / Terminal Notifier: The entire deny dialog comes up in relation to Gatekeeper, which is the bane of my existence. The way that I wrote the bundler (and it can now be considered Dean's work as much as mine) worked on the assumption that we couldn't assume if anything was denied. We went this route because if you deny it once for Workflow A but then want to authorize it for Workflow B, you can't. Basically, what it does is just ask to whitelist an application for Gatekeeper. I'll have to double-check why it is activating if you've denied it because the workflow should just be failing there.

 

But, I'm not sure exactly what you want here. Do you want to deny the bundler's use of Terminal Notifier because you don't like the bundler, because you don't like terminal notifier, or because you don't want to be notified? The three are separate issues. The first one doesn't make too much sense because, if other workflows start to use it, your Dropbox will be less cluttered — if nothing else. For the second one, that's how it's designed. I can't make use of Alfred's notification system because the processes are forked, and I can't rely on Growl to be installed. For the third, I could make that an option to have everything work entirely silently, but then you won't get any information about updates succeeding or failing.

 

Re: GUI: the GUI utility thingie comes from an automator application, and it is lazy loaded, which means that it shouldn't be downloaded onto your computer until you try to launch it. If it is, then I accidentally called it too soon somewhere.

 

@Paulw: Can you help me out with where it is failing? Did you whitelist it with Gatekeeper (via the bundler dialogs)? Are you running Mavericks or Yosemite? Is it failing before opening? If you can, try to open the GUI via Alfred, and then — quickly — point a web browser to http://localhost:7893 and see if anything comes up. The temporary webserver will kill itself if it doesn't see any action within 30 seconds, hence the "quickly." Are there any errors in the workflow debug console?

[paulw]

 

@Paulw: Can you help me out with where it is failing? Did you whitelist it with Gatekeeper (via the bundler dialogs)? Are you running Mavericks or Yosemite? Is it failing before opening? If you can, try to open the GUI via Alfred, and then — quickly — point a web browser to http://localhost:7893 and see if anything comes up. The temporary webserver will kill itself if it doesn't see any action within 30 seconds, hence the "quickly." Are there any errors in the workflow debug console?

 

I continue to get "scptl is trying to allow an item to always run" dialogs even though I repeatedly authenticate. I'm not a programmer: what do these dialogs do? I'm assuming this is the whitelisting you're talking about. Running Mavericks. Fails before opening. It does work if I point my browser to the address you gave. Debugging, I get this error:

[ERROR: alfred.workflow.action.script] Code 0: 134:141: syntax error: A identifier can’t go after this “"”. (-2740)
36:87: execution error: System Events got an error: Can’t set process "Application Stub" to true. (-10006)
[INFO: alfred.workflow.action.script] Processing output 'alfred.workflow.output.notification' with arg ''

[vdesabou]

 

I continue to get "scptl is trying to allow an item to always run" dialogs even though I repeatedly authenticate. I'm not a programmer: what do these dialogs do? I'm assuming this is the whitelisting you're talking about. Running Mavericks. Fails before opening. It does work if I point my browser to the address you gave. Debugging, I get this error:

[ERROR: alfred.workflow.action.script] Code 0: 134:141: syntax error: A identifier can’t go after this “"”. (-2740)
36:87: execution error: System Events got an error: Can’t set process "Application Stub" to true. (-10006)
[INFO: alfred.workflow.action.script] Processing output 'alfred.workflow.output.notification' with arg ''

 

FYI I had same issue this morning and opened bug here https://github.com/shawnrice/packal-updater/issues/1 but immediately close it because I've found the way to fix it by removing the data bundler directory, but I'll let Shawn confirm

[rice.shawn]

@paulw: if you haven't already, try deleting the bundler's data directory ( ~/Library/Application Support/Alfred 2/Workflow Data/alfred.bundler-aries ) and see if it fixes those two issues.

[paulw]

Yep, that fixed it. Thanks, Shawn. I've been really looking forward to this workflow, as I'm kind of a workflow hoarder.

 

Do you think there will be any way to scan non-Packal workflows and check for whether they are also hosted on Packal?

[rice.shawn]

Glad it fixed it.

 

Open the GUI. In the status tab, you should see "xxx workflows can be downloaded from packal" or something. If you don't see that, then all that are possible have already been downloaded from Packal. If you do see that, click the "details" just below that, and you'll see a list of them. If you click any of those workflows, then it'll open the workflow page on Packal in your default browser.

 

I have some commented out code in the workflow to have an option to "force packal" — the wording is terrible, which basically will automatically re-download all of the workflows that are available on Packal but you haven't downloaded from Packal yet. I haven't gotten in working in a satisfactory way for me to have it implemented, so I figured I'd delay that feature for now. Currently, it's too aggressive for my taste.

[paulw]

 

Oh, that's fantastic—it's already built in. Thank you for that, Shawn!

[rice.shawn]

I forgot to mention, if you have Alfred Cron installed, the workflow will give you an option to install a script that will check for workflow updates once per day. You can easily change the timing by editing the job after "installing" it into Alfred Cron.

 

If it finds any updates, it will notify you via Terminal Notifier. If you click the "show" button on the notification, then it'll show you the updates.

Edited July 2, 2014 by Shawn Rice

[smarg19]

Whenever I open the GUI, the `viewer.app` window is too skinny.

[vitor]

Do you think there will be any way to scan non-Packal workflows and check for whether they are also hosted on Packal?

deanishe’s workflow does that (packal status).

 

 

I think you hit the wrong "no means no," unless you meant the Canadian Punk band, which I'd never heard of before today.

The link was correct: it was purposefully tongue-in-cheek. I was going to link to their official website, which is humorously called no means whatever, but that would be even more confusing, since it’s not immediately obvious what the website is about.

 

The entire deny dialog comes up in relation to Gatekeeper, which is the bane of my existence.

The issue is with signing, correct? So if there was someone willing to sign the releases, that limitation could be bypassed?

 

Do you want to deny the bundler's use of Terminal Notifier because you don't like the bundler

Yes. I very much like the idea and the possibilities, just not really implementation. Why?

 

I continue to get "scptl is trying to allow an item to always run" dialogs even though I repeatedly authenticate. I'm not a programmer: what do these dialogs do?

 

[emphasis mine]

Because in its current state, it’s uncomfortable, confusing, and possibly frightening, to users.

 

The first one doesn't make too much sense because, if other workflows start to use it, your Dropbox will be less cluttered — if nothing else

I already encountered one. After I saw the warning, I uninstalled it. For a workflow I share (as opposed to one I build solely for myself), the overall experience is far more important than size, reusability, or modularity, since those are mostly invisible and unimportant to the user. I also don’t mind my dropbox losing a little space, since it’s pretty negligible. I much rather spend a few extra KBs (or even MBs) to have everything tightly contained in one place, than having it scattered. On that note, what happens if I delete workflows that already downloaded dependencies? Do the dependencies remain? If so, that means saving a bit of space in my dropbox is making me have old libraries linger somewhere else in the system. The idea of that bothers me a lot more.

To be perfectly clear, this is in no way a comment on the quality of your work or abilities. I’m very much aware that you understand the limitations in Alfred Bundler, and would eradicate them if you could. It’s simply that like a lot of other software, it doesn’t fit the way I like to work.

[rice.shawn]

I consider the bundler an open project and am happy for anyone to help develop it, so if you have some good ideas about how to fix them, then please help.

 

The warning is, unfortunately, something that I can't get past but an Applescript dialog should pop up before that with a bit of explanation as to what's happening. Somewhere down the line I plopped a syntax error into it, so it stopped working, but it should be working again now. If there is a more elegant way that you can think of to get authorization for Gatekeeper from those who have it turned on, then I'm open to it. I hate Gatekeeper.

 

If anyone would want to sign some of these utilities, then that would be rad. I thought about springing for the developer ID to be able to sign the code, but I don't have the extra cash for just something like that, and it doesn't get past the most strict (and default) Gatekeeper settings, which is to trust apps only from the Apple Store.

 

Libraries lingering places has been a concern of mine too. That was one idea behind the bundler: keep them all in one place and separate from your system. The bundler currently keeps a registry of which workflows use which assets. I have a half-finished workflow on my computer to uninstall workflows with their data directories, cache directories, or just the orphaned directories. It would also be there to serve as a diagnostic for the bundler to show which assets are used by which workflows and to uninstall them if they are orphaned. Dean has written a Python wrapper for the bundler which is close to being released. That one will allow workflow authors to install Python packages without needing to bundle them, but, also, they won't be installed in the system directory.

 

I'd like to find someone who knows enough about Ruby to do the same.

 

Don't worry. I'm not taking offense to anything, and I do understand aesthetic preference as to how things can work. But, if you do have ideas of how to improve the bundler to make it work better or be less obtrusive or easier to implement or really anything, then please do let me know. Just open an issue here. Or join in the conversation here. Or send me an email / PM.

 

Lastly, I think I'm about to go listen to some nomeansno.

[rice.shawn]

Whenever I open the GUI, the `viewer.app` window is too skinny.

 

I remember you were playing around with the sizing with the plist for that workflow you were writing. It should be 1024x768. Is it set to that?

[MuppetGate]

Hi Shawn.

 

Even after I update the Packal Updater, it still reads as version 0.4 and says it can still be updated to version 1.0

 

This is both from inside Alfred and the GUI.

 

Something I'm missing?

[rice.shawn]

Can you update the manifest and try again?

 

Hi Shawn.

 

Even after I update the Packal Updater, it still reads as version 0.4 and says it can still be updated to version 1.0

 

This is both from inside Alfred and the GUI.

 

Something I'm missing?

 

Hm. That's a problem that happens when the workflow author submits the new version without changing the version on Packal (here, the screwup is me). I wrote a script to do a correction for this on the server side, but there seems to be a hole in my logic. I'll work on that in just a moment.

[vitor]

the most strict (and default) Gatekeeper settings, which is to trust apps only from the Apple Store

Unless the setting has changed in Yosemite, the default is allowing from both the Mac App Store and identified developers. Apple confirms that was the case in Mountain Lion, and I just confirmed on a clean VM that that is also the case on Mavericks. That means signing the app would pretty much solve the issue. Naturally, I understand your reluctance in spending the money for such a specific case. I didn’t either.

[rice.shawn]

Unless the setting has changed in Yosemite, the default is allowing from both the Mac App Store and identified developers. Apple confirms that was the case in Mountain Lion, and I just confirmed on a clean VM that that is also the case on Mavericks.

 

You're right.

 

I didn’t either.

 

Speaking of notificator, good job on that. Would you mind if I created a sort of "empty" version of it and a wrapper that would, basically, do what the setup script does but on the fly so that it could work with multiple workflows?

[vitor]

Speaking of notificator, good job on that.

Thank you.

Would you mind if I created a sort of "empty" version of it and a wrapper that would, basically, do what the setup script does but on the fly so that it could work with multiple workflows?

Go nuts. Even before I started building it, I knew I wanted to have it under a public domain license exactly so anyone can do whatever they feel like, without even having to ask (though I appreciate the gesture). If you have any questions, let me know.

[deanishe]

Re: Bundler issues / Terminal Notifier: The entire deny dialog comes up in relation to Gatekeeper, which is the bane of my existence. The way that I wrote the bundler (and it can now be considered Dean's work as much as mine) worked on the assumption that we couldn't assume if anything was denied. We went this route because if you deny it once for Workflow A but then want to authorize it for Workflow B, you can't. Basically, what it does is just ask to whitelist an application for Gatekeeper. I'll have to double-check why it is activating if you've denied it because the workflow should just be failing there.

 

Well, I'd like to take issue with that. Not in a it's-not-my-fault way, but in a Shawn-did-99.9%-of-the-work way. My contribution has been distinctly minimal. This is his (great) idea and his work and any credit belongs to him. Let's compare it to the guy who designs and builds a race car and the guy who tightens the nuts.

[raguay.customct]

I had to turn off error reporting since you use mktime, which is depreciated. I'm running PHP 5.6.

 

Once turned off, it is working fine. Thanks.

 

You can not set the number of backups to zero. I have it one one right now, but zero would be better for me.