deanishe Posted June 9, 2014 Share Posted June 9, 2014 I think I got update.sh fixed now, and the Python bundler seems to be working okay. My work here is done Link to comment
smarg19 Posted June 9, 2014 Share Posted June 9, 2014 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. Link to comment
deanishe Posted June 9, 2014 Share Posted June 9, 2014 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 Link to comment
smarg19 Posted June 9, 2014 Share Posted June 9, 2014 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 Link to comment
deanishe Posted June 9, 2014 Share Posted June 9, 2014 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… Link to comment
rice.shawn Posted June 9, 2014 Author Share Posted June 9, 2014 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. Link to comment
deanishe Posted June 9, 2014 Share Posted June 9, 2014 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. Link to comment
rice.shawn Posted June 9, 2014 Author Share Posted June 9, 2014 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. Link to comment
rice.shawn Posted June 9, 2014 Author Share Posted June 9, 2014 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. Link to comment
deanishe Posted June 9, 2014 Share Posted June 9, 2014 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. Link to comment
deanishe Posted June 9, 2014 Share Posted June 9, 2014 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. Link to comment
deanishe Posted June 9, 2014 Share Posted June 9, 2014 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. Link to comment
rice.shawn Posted June 9, 2014 Author Share Posted June 9, 2014 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. Link to comment
deanishe Posted June 9, 2014 Share Posted June 9, 2014 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. Link to comment
rice.shawn Posted June 9, 2014 Author Share Posted June 9, 2014 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. Link to comment
deanishe Posted August 2, 2014 Share Posted August 2, 2014 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. Link to comment
smarg19 Posted August 3, 2014 Share Posted August 3, 2014 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 Link to comment
deanishe Posted August 3, 2014 Share Posted August 3, 2014 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. Link to comment
smarg19 Posted August 3, 2014 Share Posted August 3, 2014 Thanks. I'll wait for Taurus then and just put the drops in the workflow for now. Link to comment
rice.shawn Posted August 3, 2014 Author Share Posted August 3, 2014 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. Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now