Jump to content

Search the Community

Showing results for tags 'package management'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Alfred 3
  • Make the Most of Alfred
    • Discussion & Help
    • Bug Reports
    • Alfred Feature Suggestions
    • Themes
  • Alfred Workflows
    • Share your Workflows
    • Workflow Help & Questions
  • Alfred v2 Themes
  • Alfred Remote for iOS
    • Alfred Remote Discussion & Help
    • Remote Connection Troubleshooting

Categories

  • Articles
    • Forum Integration
    • Frontpage
  • Pages
  • Miscellaneous
    • Databases
    • Templates
    • Media

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Twitter


Website URL


Jabber


Location


Interests

Found 1 result

  1. Note from Andrew: While this is a convenient method for updating workflows, I cannot endorse the use of it unless you are fully aware of the security implications of blanket updating all of your workflows. I'm currently working on a built in workflow auto-updater, for a future Alfred 2 release, that performs the standard verification checks that Alfred currently does on manual import, along with migrating your hotkey/keyword settings on upgrading. I'll also be adding 3rd party workflow developer signatures to keep you safe. Hey all, I've just completed a workflow designed to make it easier for workflow developers to push updates to their work. (And to their flows.) It's called Alleyoop, it's based very heavily on the concept behind David's old extension updater, and it works a little something like this: When you enter the query oop, it searches through the workflow folders for files named update.json. update.json indicates what version of the workflow is currently installed and where to check for an update. (The format is below.) Alleyoop downloads a remote json file, indicated in update.json, and if that file indicates a higher version, it downloads the workflow at the address given by the remote file. The user finds the workflow in his or her ~/Downloads directory and opens it. There is no step 4. Workflow developers can start implementing this workflow immediately. All you need is a static place to host a json file and an alfredworkflow fileā€”so Github will do, failing all else, but Droplr won't. Place an update.json file in your workflow, with the following keys defined: { "version": 1.0, "remote_json": "http://alfred.daniel.sh/Updates/Things.json" } version should be a float, meaning that 1.0 and 1.1 and 3.14159 are all valid, but 3.1.4 is not, and remote_json should point to a json file on a remote server that's defined like this: { "version": 1.5, "download_url": "http://alfred.daniel.sh/Workflows/Things.alfredworkflow", "description": "Brief description of the update." } If the version on the remote server is greater than the version on the user's computer, s/he'll see something like this: Selecting a workflow from the list will download it. No fuss, no muss. And that's it! Enjoy implementing this, until we get a good package manager running again, and let me know if you run into any difficulties. Download Here
×
×
  • Create New...