Update via Packal about alfred-workflow HOT 17 CLOSED

Cool stuff!
I thought about adding Packal support, because Packal is hosted on GitHub anyway. I still think it'd be great if Alfred-Workflow is also compatible with Packal releases.
Instead of renaming github_slug, why not just add packal_bundle_id? The script could check which one is set...
Using dedicated classes could be overkill tho. Maybe keep it simple and use normal functions?

from alfred-workflow.

So, have if ... then checks in each function for GutHub vs. Packal functionality? Or, add prefixes to functions and do one check in _check_update()?

from alfred-workflow.

Depends on what 'looks better'.
You might as well just try using different classes! 😃

from alfred-workflow.

I thought about putting the update code in a class, but I can't remember exactly why. I think it may have been to avoid creating multiple Workflow instances, but I really don't know right now.

If we did implement Packal update support, I wouldn't condone downloading the workflow directly from GitHub. Shawn is stumping up to host Packal, and one way or another, an update via Packal would have to go via the Packal website, not directly to the GitHub repo.

Interface-wise, I don't see any point in adding new arguments to Workflow. The update code would have to check the keys in update_info (which I've provisionally renamed update_settings in the corresponding branch to match default_settings) to see if GitHub and/or Packal is specified.

I'm not convinced of the advantage of Packal support given the above condition and the following:

This isn't an official API we're talking about, so Shawn might change the XML format at any time, and he'd be perfectly within his rights to do so. I'm uncomfortable with the idea of relying on something that may change at any time. Especially as we'd just be duplicating part of the functionality of the Packal updater, which does a better job anyway (it doesn't rely on Alfred to install updated workflows).

My personal feeling is that if we were to implement a secondary update mechanism (in addition to GitHub releases), I'd prefer a generic, Sparkle-like, RSS feed-based one that isn't dependent on a particular platform, like GitHub or Packal.

I don't currently "release" new versions via GitHub. That's what I use Packal for

FWIW, it's easier to release via GitHub than Packal.

from alfred-workflow.

I'm must admit that @deanishe has a point.
I've no idea how often Shawn changes Packal's API, but he certainly could at any time.
GitHub's API is way more consistent and you don't want to have broken updaters!

Besides, I still prefer to release my workflows on Github. Like Dean said, it's a lot easier...

from alfred-workflow.

Ok. A few thoughs.

If we did implement Packal update support, I wouldn't condone downloading the workflow directly from GitHub. Shawn is stumping up to host Packal, and one way or another, an update via Packal would have to go via the Packal website, not directly to the GitHub repo.

"Stumping up"? Why not go directly to GitHub? That's what Packal does anyway.

I'd prefer a generic, Sparkle-like RSS feed-based one that isn't dependent on a particular platform, like GitHub or Packal.

As would I, but who's going to build it and how do we get people to adopt it?

FWIW, it's easier to release via GitHub than Packal.

Granted, but Alfred-Workflow is built specifically to offer top-flight functionality to "normal" workflow authors. And Shawn and the forums have done a decent enough job getting "normal" workflows to be hosted on Packal. My thinking is that having a mechanism to allow workflow authors to implement auto-updating (a top-flight feature) without having to learn Git. They already host it on Packal, and Packal has all the information we need to check for updates and download. It's a simpler path for many authors.

And, if Shawn changes the XML format (which is what I'm using), then the worst that happens is that auto-updating doesn't work. This just leaves workflows and workflow authors exactly where they are now. We can easily update Alfred-Workflow, so all they then need to do is update their workflow (the same way they would now).

I just think this would open this functionality up to a wider audience. Am I willing to release workflows via GitHub? Absolutely. But I'm not sure everyone is.

from alfred-workflow.

"Stumping up"? Why not go directly to GitHub? That's what Packal does anyway.

He pays to host Packal out of his own pocket and there are ads on Packal to (hopefully) cover the costs.

Shawn has invested a lot of time and money in Packal and I would feel uncomfortable doing an end-run around the site, thus eliminating his only opportunity to recoup at least some of his costs.

I am not willing to compromise on this issue. Any update based on Packal's metadata must go via the website unless Shawn explicitly says otherwise.

As would I, but who's going to build it and how do we get people to adopt it?

Fuck knows. I doubt that anyone would use it, but the point is I'd prefer such a generic update mechanism over one that's dependent on an API that isn't actually an API.

My thinking is that having a mechanism to allow workflow authors to implement auto-updating (a top-flight feature) without having to learn Git. They already host it on Packal, and Packal has all the information we need to check for updates and download. It's a simpler path for many authors.

That already exists with the Packal updater.

And, if Shawn changes the XML format (which is what I'm using), then the worst that happens is that auto-updating doesn't work. This just leaves workflows and workflow authors exactly where they are now.

No, it doesn't. There's a big difference (in people's perception) between not having a feature and having a broken version of the same feature.

I just think this would open this functionality up to a wider audience. Am I willing to release workflows via GitHub? Absolutely. But I'm not sure everyone is.

As noted above, the Packal updater already provides this functionality.

from alfred-workflow.

Well, not this functionality. For me, as a workflow author, I have no control over whether or not any of my users has the Packal Updater workflow. I therefore have zero control over whether or not users are aware of when updates are available. What I like about this feature is that I can prompt users whenever an update is available. If they have my workflow, then they will know when they can update that workflow. That is quite different from hoping that users also have and regularly use the Packal Updater.

Now, I'm primarily interested in me, so I won't fight to add this workflow-based auto-updating feature with a Packal backend. I will merely switch over to GitHub releases. That said, I am also willing to add the minimal functionality to have a notice (like @fniephaus' Pocket workflow) when an update is available, and when you select it, it will simply open the Packal page for that workflow. This is simple, but also covers all of the concerns. I'm all for helping Shawn out. I just didn't understand the turn of phrase. I also don't care what degree of "automation" the feature has. So, if its amenable, we can simply add Packal support in this limited manner. Or, we can do nothing, and I'll simply change to GitHub.

from alfred-workflow.

How about doing something similar to with the serialisers and creating a class-based system whereby it's easy to add support for other mechanisms? There would only be GitHub included by default, but it'd be easy to add Packal or RSS feeds or whatever.

Rather than having to explicitly add updaters, they can be automatically registered by subclassing a base Updater class (I use this technique when I want to add simple plugin support to something. It works rather well).

Each concrete Updater subclass would have to implement 3–4 methods:

• a class method can_update(update_info) which returns True if that class can perform updates based on the contents of update_info (e.g. GitHubUpdater.can_update(update_info) would check for the presence of github_slug and version, PackalUpdater.can_update(update_info) would check for the presence of packal_url and version). An error would be raised if update_info is present but no Updater subclass that understands it can be found.
• a check_for_update() method that gets run asynchronously using background.py.
• an update_available property that returns True if a newer version is available.
• an install_update() method that downloads and installs the newer version.

The install_update() method could probably go on the base class provided check_for_update() saves the download URL of the new version.

I'd feel a lot more comfortable with this solution, as then I don't have to officially "bless" (and therefore support) Packal updates, but it should be fairly trivial to add, and you'd be free to grab the updated workflow files straight from Packal's GH repo if you prefer.

You could also add an alternative GH updater that doesn't require the use of releases, but grabs the file straight out of the repo.

Would that work for you?

from alfred-workflow.

Sounds reasonable!

from alfred-workflow.

Just to weigh in here...

So far, I haven't changed the Packal "API" yet except to add some stuff to it so that Dean could make his Packal workflow search better. If, for some reason, other people start building tools that play with it, then I'll go out of my way to keep it stable or at least version it so that there is a "legacy" API that will continue to work if I change it. And I'm open to adding to the available data if others find a use for it.

There is a pretty simple way to tell if the workflow was downloaded from Packal, which is to see if there is a "packal" folder in the workflow root. In that directory, you'll find a pubkey and an xml file.

FWIW, it's easier to release via GitHub than Packal.

That is completely true. I still need to find the time to make it so that updating a release on Packal can be done in the same step as pushing a release to Github or something just about as easy. That is planned, and some code for that has been written. Still, there is the need to find the time to finish writing, test, and then implement. But, in terms of improvement to the site, workflow submission / updating is on top of the list.

He pays to host Packal out of his own pocket and there are ads on Packal to (hopefully) cover the costs.

Thanks, as always, for keeping that in mind. I do run the site at a loss. Hopefully, one day, ad impressions will cover the cost of the site.

I use GH as a backend for two main reasons:

1. It offloads traffic from my servers when it's not needed; and
2. The entire repository will continue to exist if Packal ever goes belly-up.

I do plan on keeping Packal alive, but I've seen enough community tools wither that I wanted the security for everyone else to know that I wasn't holding their data hostage.

I do look at Packal as a community tool, and I'd rather try to consolidate the tools around the site in order to make things as simple as possible to distribute, download, and update workflows. It does nicely bring together the workflows in a way that makes it easy for people to find new ones if they just come to the site to download one, then they get to browse through and see the others. So each workflow that goes up on the site helps the visibility of all other workflows there as well.

I do have some other code that didn't make it into the Packal updater that would make it so that you could update workflows that you didn't download from Packal but were still hosted on Packal. One problem that I run into is that I can't determine the version of the workflow that wasn't downloaded from Packal because there is no reliable way to do so. The second is that it feels somewhat aggressive to me for the Packal updater to just take control of all of your workflows.

For the updating itself, I did have several long conversations with Andrew about how he felt most comfortable in making that work. Some of that happens on the server, and some of it happens on the user's machine when I rewrite the plists of the new version based on a few standard rules and other information from the old plist that was installed. If anyone does ever decide to make their workflows auto-updating, then they should dig through that code and duplicate its functionality.

But, as I mentioned above, I do look at Packal (and the updater, etc...) as community tools, and so I'm also open to community collaboration on this front. If you'd like to see other functionality in the updater workflow, or if you want to see a difference in how the updater workflow functions, then I'm more than happy to discuss / collaborate, etc... to make that tool better rather than needing to rewrite the functionality.

from alfred-workflow.

@shawnrice If you intend to keep the repo/XML format stable, no reason why there can't be a Packal updater, too.

Any chance of the XML files in Packal's repo providing the Packal URL to the workflows' respective pages on Packal?

That's no biggie: authors would have to specify somehow that they want to update via Packal, and they can pass packal_url=http://www.packal.org/... instead of packal=True, but it'd be handy for my Packal search workflow, so I can send users right to the proper page (if the URL is in manifest.xml, too).

from alfred-workflow.

Going through the last comments, I'd suggest that we don't integrate Packal in alfred-workflow. I wouldn't mind an additional and more universal solution tho...
Instead, @shawnrice could rather add updating capabilities to Packal itself. This way it'd be easier to deal with API changes and it makes more sense to maintain it there anyway.
Not sure how far @shawnrice got with this feature, but he might be able to just reuse some of @smargh's gist posted above.

I honestly have no idea why workflows have a name, a description and even a bundle id but no version tag! It'd be great if Andrew could soon catch up on this! :)

from alfred-workflow.

@fniephaus: do you mean this: http://www.packal.org/workflow/packal-updater?

A version tag would be pretty damn great.

@deanishe: I'll update the manifest to have the URLs shortly.

from alfred-workflow.

@shawnrice thanks! I'll have a look at it as soon as I can...

from alfred-workflow.

I honestly have no idea why workflows have a name, a description and even a bundle id but no version tag! It'd be great if Andrew could soon catch up on this! :)

Probably because he doesn't really write any workflows himself. I think Alfred would be a lot more workflow-friendly if Andrew had also written some substantial workflows.

from alfred-workflow.

Closing this issue.

A generalised update mechanism is on the roadmap for v2.

from alfred-workflow.