deanishe

Atom/node packages don't *have to be* published in the central repository, only if they want to be installed merely by name (or included in Atom's UI). You can't force people to publish their work in a particular place, but if we push Packal as *the* place to go, it may become a de facto central repository (like PyPi) if not a de jure one. Versioning would be useful, and Packal already understands versions, but it currently doesn't support multiple workflow files (e.g. previous versions) per entry. You could ask Shawn to put it on the wishlist.

Try Packal.org. Here's a workflow to search the site. One that can update your workflows is in the works. A command-line solution (like npm or Atom) isn't a good solution for non-developer tools (though I'd be happy to have one).

Wouldn't have been my first (or even fourth) choice as a new scripting language of OS X, but it sure is a massive improvement on AppleScript. Man, I hate that language. This is one time I'll be happy to reimplement loads of my code in a new language.

I understand he's talking about some kind of completion. But what? Does he want to run a live bash/zsh session in Alfred? Does he want to see the titles/cwd's of tabs currently open in Terminal/iTerm 2?

I'd like to see them try…

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.

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.

Here. return vs exit in bash.

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.

Oh yes there is… The code was working, you know. You return from a function, exit from a script.

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.

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…

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

Glad to hear it.

I think I got update.sh fixed now, and the Python bundler seems to be working okay. My work here is done

I've changed the Python bundler to take care of installing/updating Pip itself and to run update.sh every week. Still trying to fix the errors in update.sh.

The "proper" way to do it would probably be to change the workflowdir() method to start looking in the current working directory instead of its own location. I wrote it the way it is in order that the code would still work if called from outside the workflow directory (in Terminal, basically). There may be a way to figure out the directory of the calling script—that would be optimal. If you just pass in a path to the plist and have the library installed outside of your workflow's directory, workflowdir() and dependent methods will be broken. It isn't. Python works this way because it has implicit namespaces (so you don't have to do silly stuff like start your functions with __ or some other prefix to—hopefully—avoid name conflicts). It's really not a problem once you understand how it works (i.e. sys.path). Also, as discussed elsewhere, it allows Python to bundle a huge number of libraries by default without having to load them all every time. Admittedly, it would be great if Python has some concept of versioned libraries. Yeah. This is kinda frowned upon. Forking is the "proper" way to do it, and also rather excessive in this case (IMO). Well, what I wanted to store there was most definitely cache data, but it's no biggie. Oh, I won't be doing it any time soon. I'm just wondering if I should bundle the bundler or recommend bundler as a way to install the workflow library. Probably the former, tbh. I'm using TN (seeing as it's already there). I think setting a module-level flag is the simplest solution (though I don't know why a developer would want to turn it off).

Also, I added code to the bundler to notify the user when Python dependencies are being installed. It takes a good few seconds in the best case, so I figured it makes more sense than dumb silence and an unresponsive workflow. Should I leave that up to the workflow developer instead, or set a flag so they can disable it?

Makes sense design-wise, but I don't see much point in creating the pip executable: it's more dangerous than anything. If it isn't called correctly, it will install stuff in the system Python, which is bad. There isn't really such a thing as a Python asset in the bundler sense: they don't work the same way as PHP/bash. At any rate, I've given the Python bundler its own "bundle ID" and assets/python subdirectory, and I will stick pip in there instead. Yeah, I would do the same. And similarly, I would only call update.sh if other stuff is being installed: Running stuff in the background isn't quite so straightforward in Python (the main script won't exit till all subprocesses are done), and it seems prudent to only run it when a network connection is required in any case. No, the cache directory isn't deleted at reboot. It's just intended for data that can be deleted without messing things up. What is "Alfred Python" (there are several libraries of that name), which "initializer" and why would you want to pass a plist to it? WRT the Python bundler, you should be able to install any package on PyPi and any package on GitHub that has a setup.py file. I'm probably going to add my own workflow library to PyPi soon. I haven't decided yet whether I should include the bundler in the workflow library or recommend installing the library via the bundler… I suppose I could do both.

Err … I could, but the bundler just made it so easy But seriously, it shouldn't be a problem if you think that's better. Thinking about it, I could try to update pip every time a workflow wants to install something. That would hide the performance hit I haven't really given any thought to a proper uninstaller: I just wanted a quick something to help me test better. One more thing that had me scratching my head for a bit: the bundler deletes its cache directory. Could it be modified to only delete the temporary files instead (I wanted to keep some stuff in there)? Have you looked at the Python bundler? It's mostly a rip of your code The only "clever" part is the newly-added function call caching, which I largely ripped from the wiki.

I wasn't thinking of a utility for the user, more something to make testing/development easier. Something significantly smarter would be required for users, and with some kind of UI, to boot. So you're planning an accompanying workflow to manage the bundler? WRT to Python, uninstallation is a piece of cake: run through the workflows directory and grab all the bundle IDs, then delete any subdirectories of assets/python that aren't in the list of bundle IDs.

Obviously, the php calls are irrelevant compared to the time it takes to install stuff. I still have Gatekeeper on, but it seems to go quiet after you've said yes once. Do you know how to reset it? Why does registry.php need to run every time? Can't it create a cache file that can be grepped, and only run if the entry doesn't exist? I've noticed that the first run can take a very long time if neither the bundler nor dependencies are installed. Is there any way we can notify the user sooner? At the least, shouldn't we notify the user whenever something is being installed?

So, I added caching of the calls to bundler.sh to bundler.py: Calling `bundler.init()` 10 calls in 0.0449 s (0.0045 s/call) Calling `bundler.utility("cocoaDialog")` 10 calls in 0.0002 s (0.0000 s/call) I'd say the performance problem's solved for the Python version I also added an uninstaller script. Hope that's okay.

You only need to select Dollars with bash (by default it expands $1, $2 etc., plus a few others, inside double quotes). For Python code, assuming you're using var = "{query}" and not var = '''{query}''' or some such, escape Backslashes and Double Quotes. Leave everything else unselected.

In Python: from time import sleep sleep(2) # seconds In bash: sleep 2 # seconds To determine if the host is already online, you can try pinging it.Bash: ping -o -t 1 192.168.0.1 if [[ $? -gt 0 ]]; then echo "Offline" else echo "Online" fi -o means exit after receiving one response, -t 1 means 1 second timeout.Python: import subprocess retcode = subprocess.call(['ping', '-o', '-t', '1', '192.168.0.1']) if retcode > 0: print('Offline') else: print('Online') How's that for you?