deanishe

I've just had a look at the "Alfred Workflows for Advanced Users" tutorial, and there's a 142-line PHP script to be pasted in a Run Script box, so let's split the difference. Might just be that I make an extremely high number of errors when I'm coding, but the thought of writing anything over, say, a dozen lines in that Script box makes my eye twitch a little. Completely tangentially, was there any particular reason to use Go for the workflow, and would you recommend it? Also, do you have any tips regarding getting into Go? It's an intriguing language, and I think I'd like to give it a try.

A noble goal—and the right method—for Workflow 101-type tutorials, but when we're talking about a self-confessed advanced tutorial with scripts that run to hundreds of lines of code, writing such scripts in the Script box isn't "keeping it simple" any more. I don't know where you got the idea from I was recommending an IDE, but you're doing the readers a disservice by implying that the Script box is the right place to write a 300+ line script. It isn't. Any basic programmer's editor with syntax highlighting and line numbers is a much better place for that. The workflow tutorial doesn't need to be an editor tutorial, but it makes sense to point out that if you're writing such long scripts, a programmer's editor makes that one heck of a lot easier, even if when you're finished, you copy-paste the code into the Script box. Sure, mentioning an editor adds some complexity to the discussion, but not doing so makes writing workflows appear harder than it really is. Trying to debug a bunch of grey text in a box with no line numbers is way harder than in a real editor, and the run-edit-run cycle in Alfred is slower and more complex, and has significant disadvantages compared to using Terminal.

Sorry, not going to do that. Might I suggest using one of the other workflow libraries that doesn't depend on lxml. It's a pretty excessive requirement just to generate a bit of XML. lxml is notorious for being horrible to get running on OS X, and while it's brilliant for XML/HTML parsing, it's really big and over-the-top for generating workflow feedback. Python's built-in XML libraries are more than good enough for that. Nikipore's workflow library works in a very similar way to the one you're using.

lxml has a much nicer interface for generating XML and it's ridiculously fast. Pretty much anyone who codes Python has it installed. I imagine datysho is just used to using it. I know I use it for everything I don't intend to distribute. But it is a complete and utter bitch to compile on OS X. Stuff of nightmares.

To edit the languages, you need to edit the code in the Script Filter. To remove Russian, for example, comment out (add # to the beginning of the lines) the two lines starting with ru_translation = ... and the ru_translation, line in the print alfred.render([... block at the end. For Ukrainian, comment out the 3 uk_translation lines. Use the same procedure to deactivate the uppercase/lowercase/title case results (3 lines per item). To change the languages, either copy the 3 ru_translation lines and change them to, say, es_translation and change to_lang="ru" to to_lang="es" in the first of the three lines. That'll give you Spanish results. @datysho: The workflow is throwing errors for me now. My Mavericks system doesn't like the lxml library: ImportError: dlopen(lxml/etree.so, 2): no suitable image found. Did find: lxml/etree.so: mach-o, but wrong architecture Might I suggest using Python's built in xml.etree library? It doesn't have the cool builder interface, but it'll work on all versions of OS X/Python.

Wish I'd noticed this workflow before. Very handy!

You seem to have a certain affinity for strange errors, Jono. I wonder what your OS install must look like

What Richard said: TaskPaper is extremely good, and extremely flexible. As it uses text files, it's extremely well-suited to hacking and automating via Alfred and other tools. The format is also widely supported. If the TaskPaper app is too expensive, no matter. You can download TextMate for free and install the TaskPaper extension.

Not sure if this is quite the right thread, but if you're distributing a workflow written in Python, *do not* ask users to install Python libraries in the system Python. Bundle them with your workflow. It's not ideal, but installing libraries into the system Python is very bad form. The chances are good that you'll break some other software doing the same naughty thing—or it will break your workflow—by installing an incompatible version of a library. It's trivial to install libraries directly in your workflow with "pip install --target=my/workflow/dir". Do that instead. In addition, bundling the libraries with your workflow means the workflow will sync across machines without problems.

Hi datysho, You shouldn't be messing with the default system Python. Well, you can mess with your own, but not other folks' (though changing the system Python is generally a bad idea). You should install the required libraries directly into the workflow with "pip --target=my/workflow/directory" before you distribute it. There are a few reasons: firstly, it's possible that your workflow/app/whatever requires a different version of a library to some other software. You can't install both versions, so one of them will end up broken. Secondly, your software may break on a system update and certainly won't sync between machines. If you install the libraries directly into your workflow, it will sync between machines and still work. Finally, if you ensure your system Python is pristine, you can be fairly certain that code you send to other Mac users will run without problems. It's very easy to forget that a library you're using is one you've installed and not a standard Python one. I keep my custom Pythons in /usr/local/bin (which is what brew does, and for a good reason) and never mess with the system one.

Hi Sebastian, Do you think you could follow the above debugging instructions and send me the generated files? I'll PM you my email address.

Great idea for a workflow. I know I'm getting on your back about this but the escaping is wrong again. With bash and PHP, you need to select everything but Spaces, Semicolons and Brackets or stuff can break.

That is trivially simple to do, but you'd have to accept that some information has probably gone missing when generating the slug. In Python, you'd just do: title = slug.replace('-', ' ').title() Trying to put back non-ASCII characters, however, is a can of worms.

Haven't the faintest idea, I'm afraid

It doesn't handle dependencies. That's kind of a big thing: Python libraries very often build on others and are made with the assumption that pip (or equivalent) will be used to install it and any dependencies. If you want to throw dependency support in the bin, then that gist seems a good place to start. But that's a whole other can of worms to be opening. It may well work—workflows generally don't tend to rely on libraries with a lot of dependencies—but you'll probably have a lot of support requests to field from people who don't understand why it doesn't work like they expect (Python libraries often aren't very upfront about their dependencies, as it's assumed pip will be taking care of all that), and you're basically offloading the parsing of setup.py or requirements.txt and dependency handling to the user (and both those files will have been hidden away somewhere deep in the bundler's data directory or deleted upon installation).

A few new features: Supports Alfred 2.3 modifier-specific subtitles Multi-word queries Running background scripts, so you can still show (cached) results while your workflow fetches new data. Basic accent-folding to search non-ASCII text with ASCII queries (e.g. munchen will match München)

He wants to add custom web searches via Alfred's query box.

You need to precede all the calls to VBoxManage in the virtualbox_control.sh script and workflow Run Script action with ssh user@machine.name, e.g.: VBoxManage list vms -l | sed -n -e '/^Name/N' -e '/\nGroups/P' -e '/\nGuest OS/p' -e '/^Guest OS/P' -e '/^UUID/P' -e '/^State/P' > ~/Library/Caches/com.runningwithcrayons.Alfred-2/Workflow\ Data/dk.aiyo.VirtualBoxControl/vms becomes: ssh user@machine.name "VBoxManage list vms -l | sed -n -e '/^Name/N' -e '/\nGroups/P' -e '/\nGuest OS/p' -e '/^Guest OS/P' -e '/^UUID/P' -e '/^State/P'" > ~/Library/Caches/com.runningwithcrayons.Alfred-2/Workflow\ Data/dk.aiyo.VirtualBoxControl/vms

Sure it can. You just use the path to the script in your Run Script action: /bin/bash /Users/me/bin/gifify "{query}"

The default behaviour is to copy files between different drives but move them on the same drive. If it says "move" it really should move the files.

Those files are no good, I'm afraid: they're just updates, so I can't install them.

It's not exactly clear what you want (you've given us some output, but not the corresponding input), but you can probably throw most of the code away and just replace "smb:" / "afp:" with "file://".

It behaves as expected on my machine (i.e. doesn't start VLC if it isn't running).

Running the try ... except clauses in the bundler probably wouldn't hit performance noticeably (it's very fast in Python). The importing would take much more time, but that has to be done anyway. The problem I see with having the bundler try to import libraries itself and install them if they're missing is that the "install name" of libraries is often different from the "import name". For example, for the standard MySQL package, you use import MySQLdb but pip install MySQL-python. So you'd have to specify both names in the call to the bundler: import bundler bundler.load('requests==2.1', # "normal" package ('MySQL-python>=1.4', 'MySQLdb'), # tell bundler install/import names differ ('git+https://github.com/deanishe/flask-login.git', 'flask.ext.login') # GitHub fork with additional/fixed features ) import requests import MySQLdb as mdb from flask.ext.login import LoginManager … The equivalent using requirements.txt would be: requirements.txt requests==2.1 MySQL-python>=1.4 -e git+https://github.com/deanishe/flask-login.git Python: import bundler bundler.load() import requests import MySQLdb as mdb from flask.ext.login import LoginManager … I think that's a cleaner API and it would make bundler easier to implement.

There really isn't a simple way around multiple copies with Python. As noted in our emails on the subject, the super-smart folks in the Python community who write pip and do packaging etc. haven't gone near versioned libraries and have chosen virtualenvs and multiple copies instead (which is now included in Python 3). I think on balance the libraries should be installed in the bundler's directory. They're provided by the bundler, and workflow authors shouldn't really have to worry about what bundler is doing behind the scenes, which they would if it were putting stuff in their workflows' directories. That would require the bundler to understand Python packaging, however (Python libraries aren't necessarily stored in a directory with the same name as the library), and as we've discussed, there simply isn't a standard way to get the version of an installed library. The bundler could write its metadata to a .bundler file in the directory where the libraries are installed. Using try ... except would add a lot of clutter to workflow scripts. Asking authors to write a requirements.txt file is not ideal, but I think it'd be less work—and less error prone—than having to wrap all imports in try ... except clauses with bundler.install statements. In particular, you'd only have to specify the library and version once (in requirements.txt), not in each Python file, so there's less chance of forgetting to update the version number in one of them. I suppose the API could work in different ways, depending on the complexity of the workflow. If you only have one Python script, it would be simpler to do: import bundler bundler.install('requests==1.1') import requests And for larger workflows you could just do: import bundler bundler.install() ... and it would use the requirements.txt in the workflow root directory (or throw an error if it's missing). That makes complete sense with PHP/bash where namespaces are not really a thing, but it's un-Pythonic, especially using __ as the prefix, which is Python for "Don't use this function/method, it's private". The API should be in line with the conventions of the language it's aimed at, not standardised across implementations, IMO.