Alfred Dependency Downloader Framework

[deanishe]

I think I got update.sh fixed now, and the Python bundler seems to be working okay.

My work here is done

[smarg19]

This is really great. I've just updated ZotQuery to use bundler and things are looking good. I'll let you know if I get any error reports or anything; now that bundler.py is in the wild and all.

[deanishe]

I'd say it's a bit too beta to use in production yet.

 

The Python version is getting fairly large now, and a lot of the code might be better off pushed into the main bundler where it can be updated.

 

The pip updater, for example, is epically hacky, as pip seems incapable of updating itself when using --target.

 

Still, always good to have beta testers, and rather you than me 

[smarg19]

Well, if it changes over time, I'll update. But it was working smoothly for me. And what's the point in building stuff if you can't break it just a little

[deanishe]

Sure, but I don't want to have to worry about breaking your stuff.

 

Anyway, we'll have to see what Shawn has to say. It's his baby, and he gets to choose when it's in a useable state.

 

When exactly did you push the update?

 

I either fixed the updater this afternoon or completely broke it…

[rice.shawn]

I think I got update.sh fixed now, and the Python bundler seems to be working okay.

My work here is done

 

I changed all the 'returns' to echo / exit. Unfortunately, there is no 'return' in bash.

[deanishe]

Welp, I just pushed another fairly large update to the Python bundler to ensure it updates all external files if they've changed.

 

It shouldn't break existing installations (I think the metadata is still compatible), but might.

[rice.shawn]

Right now I'm okay with 'epically' hacky as long as it works. We can always work out less hacky methods for the next major version.

[rice.shawn]

Actually the nohup .... & is the way to fork a process in bash. The nohup just makes it so that none of the output is pushed back to the script/shell, which seems important.

 

I know that for PHP, this sort of thing matters because exec() or shell_exec() will sit around and wait for the process to be done, so forking is necessary there.

[deanishe]

I changed all the 'returns' to echo / exit. Unfortunately, there is no 'return' in bash.

 

Oh yes there is…

 

The code was working, you know. You return from a function, exit from a script.

[deanishe]

Actually the nohup .... & is the way to fork a process in bash. The nohup just makes it so that none of the output is pushed back to the script/shell, which seems important.

 

I know that for PHP, this sort of thing matters because exec() or shell_exec() will sit around and wait for the process to be done, so forking is necessary there.

 

I'm not calling it from bash…

 

It doesn't matter: I call update.sh first, then see about updating pip and the wrapper script while it's doing its thing.

[deanishe]

Here. return vs exit in bash.

[deanishe]

What's more, this won't work as intended:

  if [[ $status -gt 0 ]]; then
    echo "Update failed" >&2
    echo $status
    exit $?
  else
    # Run update-the-bundler.sh
    /bin/bash "${file}"
    echo $?
    exit $?
  fi

$? is the exit status of the last run thing, so in those cases your calling exit with the result of echo statements, not the previous command.

[rice.shawn]

Hm. I thought I had read otherwise other places. Maybe it was between different versions of Bash or something. But having return does make things easier again. And you're right about the order of the $?. I changed them without thinking.

 

Anyway, I reverted update.sh to your version.

[deanishe]

Righty. I'd better update my local version again, too.

FWIW, calling bash scripts with sh or /bin/sh is not advisable: it is bash on OS X (though it didn't use to be), but it's dash on Ubuntu, for example. Best to explicitly use bash.

[rice.shawn]

Righty. I'd better update my local version again, too.

FWIW, calling bash scripts with sh or /bin/sh is not advisable: it is bash on OS X (though it didn't use to be), but it's dash on Ubuntu, for example. Best to explicitly use bash.

 

True. It's actually better not to call it with either because it spawns a subshell (as far as I know). But, for now, it's fine because it's always Bash on OS X, and I don't think that anyone will be using Alfred outside of OS X.

[deanishe]

 I'd like to see them try…

[deanishe]

I've added a demo workflow using the Python bundler to Packal.
 
It doesn't do anything useful (shows a few icons and dates), but the source code shows how to use the three main features (automatic, transparent installation of libraries, utilities and icons), and it extensively commented.
 
Usage:

• bundleicons [<query>] — Show 5 FontAwesome icons, either randomly chosen or matching <query>
• bundlecolour — Choose a new HTML/CSS colour for the icons. Try entering an invalid colour to see an error dialog.
• bundletime — Shows the current time in a bunch of random timezones. Uses the pytz library, installing it first if necessary.

[smarg19]

I am using this for Pandoctor and a user just reported this error. Any help or suggestions?

[ERROR: alfred.workflow.action.script] Code 1: [aries.zip]

End-of-central-directory signature not found. Either this file is not

a zipfile, or it constitutes one disk of a multi-part archive. In the

latter case the central directory and zipfile comment will be found on

the last disk(s) of this archive.

unzip: cannot find zipfile directory in one of aries.zip or

aries.zip.zip, and cannot find aries.zip.ZIP, period.

mv: rename alfred-bundler-aries/* to /Users/stephan/Library/Application Support/Alfred 2/Workflow Data/alfred.bundler-aries/*: No such file or directory

[terminal-notifier.zip]

End-of-central-directory signature not found. Either this file is not

a zipfile, or it constitutes one disk of a multi-part archive. In the

latter case the central directory and zipfile comment will be found on

the last disk(s) of this archive.

unzip: cannot find zipfile directory in one of terminal-notifier.zip or

terminal-notifier.zip.zip, and cannot find terminal-notifier.zip.ZIP, period.

cp: terminal-notifier.app: No such file or directory

/Users/stephan/Library/Caches/com.runningwithcrayons.Alfred-2/Workflow Data/alfred.bundler-aries/installer/installer.sh: line 63: /Users/stephan/Library/Application Support/Alfred 2/Workflow Data/alfred.bundler-aries/assets/utility/terminal-notifier/default/terminal-notifier.app/Contents/MacOS/terminal-notifier: No such file or directory

/Users/stephan/Library/Application Support/Alfred 2/Workflow Data/alfred.bundler-aries/assets/python/net.deanishe.alfred-python-bundler/bundlerwrapper.sh: line 76: /Users/stephan/Library/Application Support/Alfred 2/Workflow Data/alfred.bundler-aries/bundler.sh: No such file or directory

/Users/stephan/Library/Application Support/Alfred 2/Workflow Data/alfred.bundler-aries/assets/python/net.deanishe.alfred-python-bundler/bundlerwrapper.sh: line 49: __loadAsset: command not found

[deanishe]

It was probably a connectivity error, by the looks of it. The main bundler archive wasn't downloaded correctly, and the bundler wrapper isn't yet smart enough to recover from that (one of the reasons it's still really not production ready).
 
Unfortunately, there also isn't an easy way to uninstall the bundler, so it can try again. Ask your user to delete their ~/Library/Application Support/Alfred 2/Workflow Data/alfred.bundler-aries directory and try running the workflow again (with an Internet connection).

 

You might want to consider adding a command to your workflow that can delete the bundler until it's stable.

[smarg19]

Thanks. I'll wait for Taurus then and just put the drops in the workflow for now.

[rice.shawn]

We're trying to bake in as much error handling and reporting into Taurus as possible, so if we do the job right, then this sort of thing will be preventable in the future.

 

This was going to go into the next version of Aries, but there were enough reasons to rewrite, basically, the entire bundler in ways that would be incompatible with the wrappers that bind the major versions.

 

With any luck (and a bunch more work), we'll get that version out for public consumption soon.