smarg19

I'm sorry that I'm so thick-headed on this issue. In retrospect, the solution is so elegant. My manic desire to organize blinded me, however. Thank you for your help. Quick question tho. When I re-installed pyzotero, feedparser, pytz, and requests to the workflow's root directory using pip, the following directories were also created: * pytz-2013.9-py2.7.egg-info * Pyzotero-0.10.1-py2.7.egg-info * feedparser-5.1.3-py2.7.egg-info * requests-2.2.1.dist-info The googling I did suggested to me that it would be safe to delete *only* these directories after the build was completed. Since I'm trying to keep the workflow as light as it can be, removing un-needed directories and files is desired. Can these directories and their files safely be removed?

Here. Sorry

Sorry for the delay, I've put the most up-to-date version on my GitHub page. Specifically, the problem is pyzotero importing its non-standard dependencies. If the modules are installed on my machine, everything works well, but if I use a standard Python dist., the imports all break down. There's no specific example, since it's the whole complex of pyzotero <-> pytz <-> requests <-> feedparser...

I've pip installed pyzotero directly into my workflow folder, and all the dependencies came with it. Here's the problem: all the dependencies make these relative imports, and these all break when everything is in the workflow folder. I've started down the path of manually changing them, but that's a fool's errand. How can I put everything in one place, but have them all import each other smoothly? It's driving me crazy...

I concur. Finer control over notifications would be a boon. At the absolute bare minimum, allowing a workflow to dynamically populate both the title and subtitle fields would be nice. Right now, since you can only use {query}, one of those fields will have a fixed message.

I tried a few methods and in the end found that regex subs was easiest. In my testing, alp would HTML encode the JSON string when creating the XML Alfred feedback. When I got that feedback in the next step, however, it would space escaped. (I've found Alfred consistently space escapes {query}). So, on the receiving end, I use: import alp import json import re inp = alp.args()[0] # For example #inp = """{"path":\ "/Users/user/path/to/file.txt",\ "query":\ "this\ is\ my\ sample\ query"}""" x = re.sub(r"\\\s", " ", inp) data = json.loads(x) print data['query'] This works well for me so far.

I feel my question wasn't clear. My fault. I simply want to pass a JSON formatted string as the argument for an item in script filter. Let me define my terms tho. In alp, the Python module I use, the dictionary key used when creating items for feedback in a Script Filter that corresponds to the value that will become {query} in the next chained action is "arg". So I'm speaking of the argument that is passed for the chosen item in a Script Filter, which will be the {query} of the (say) chained Run Script action. For example, let's say I have a script filter "query Jones" and it returns 3 items: * Tom Jones * Mike Jones * Andy Jones If these are valid/active items, I can click on one of them. Within the workflow, each of these items has an argument which will passed to the Run Script action that is chained to the Script Filter. (I know I'm being redundant and we all know this, but I'm trying to be clear via example this time). Normally, that string argument is simple. Let's say that in this case it is: * Tom Jones = "tom" * Mike Jones = "mike" * Andy Jones = "andy" If I select the Andy Jones item, then the value of {query} in the Run Script action will be "andy". This is all straight forward, but what if I want to pass more complex data? What if I want to pass each item's First Name, ID, and Height (3 values)? A simple way to represent complex key-value pairs is JSON, which can be put in string form (I know that I can't pass a Python dict as the item's arg). So, what I would want as the args would be: * Tom Jones = "{\n\t'name': 'tom',\n\t'height': '5.0',\n\t'id': 3\n}" * Mike Jones = "{\n\t'name': 'mike',\n\t'height': '5.5',\n\t'id': 2\n}" * Andy Jones = "{\n\t'name': 'andy',\n\t'height': '6.0',\n\t'id': 1\n}" If I pass this string as the arg, in the Run Script, I can decode the JSON string to a Python dict and easily get at the multiple values. Now, my question is, can I do this? Can I pass a string arg that has new lines (\n) and tabs (\t), necessary for JSON, in order to pass multiple values through an argument? If not, then what are the best methods for passing key-value pairs through Alfred's arg?

Honestly, that is brilliant. I deleted pyzotero and did a fresh install directly into the dependencies folder. Pip automatically downloaded all necessary dependent packages, and a test run ran smoothly. I think you're 100% correct that dealing with user system stuff is unnecessarily painful. I've had way too much trouble with my initial set-up. What I've found as well is that if you delete the .pyc files before uploading, the workflow still isn't very large. Its less than 2 MB now. At one point, I had a bloated version around 6 MB. I would say that having the workflow creator pip install any dependencies into a `dependencies` folder is probably the easiest, simplest solution. Thank you so much for your help. I'm currently working on another large update that will add alot of functionality that revolves around Zotero's write API. I'll def send you a PM if I have any questions, but I'm pretty close now. Once again, thanks.

Good point on the list. I ran a script to just grap all of the import statements in the whole workflow. I'll go through and shorten the list. I am currently researching and testing to teach myself more about Python package management. Firstly, I didn't know that installing one module (pyzotero in this case) via pip will automatically install its dependencies. This means it would actually be easier not to bundle pyzotero with the workflow. The problems I found when trying to bundle packages/modules within the module always centered on explicit import statements. I was trying to use relative imports to specify the package/module in the workflow folder I had bundled. Given my general ignorance, this had tons of problems. I see now that adding a package folder to the sys.path will probably be easier. All of this new knowledge is leading me to rethink ZotQuery set-up. One question though: Let’s say I change the configurator to install pyzotero with its dependencies (is this unique to pip, or does easy_install automatically install dependent packages/modules as well? I ask, since not all users will have pip, but easy_install comes standard. If only pip, I will need to install pip first). Let’s say I also tell pip (or easy_install) to download all of these packages to ZotQuery’s Workflow Data folder. I will then need to add that folder to sys.path (can I do this in the bash script for the configurator, such that it is universal? Or will I need to add a line to each Python script to add the ZotQuery Workflow Data folder to sys.path before any imports?). Assuming all this, will the basic import statements in pyzotero function properly? So that, if pyzotero.zotero imports pytz, and both pyzotero and pytz are stached in the Workflow Folder, since this larger folder is in sys.path, things should just work as is, right? I’m sure this is a bit dumb, but I’m only now getting into the skeleton of Python. So the details of package management are currently beyond me (tho I am assiduously learning).

I tried to search and find an answer to this question, but couldn't. If it's out there, I apologize. I did actually try before posting. Howerver, I'm wondering about the sophistication possible in the strings passed as arguments in script filters. I've seen a number of workflows that pass multiple pieces of data separated by some custom delimiter, but even then, it's typically no more than 3 items. I'm wondering what the specific limitations there are in script filter arguments? Is there some character count? Would the tab and newlines in a JSON string be mangled? If one wants to send a decently large amount of data through the arg, what's the best method? Obviously, I have the specific question of whether one can pass a JSON string. However, I would also like to know a few more technical details about why yes or no. And generally how the argument functions in script filters.

As a stop-gap, I rewrote my script that checks for necessary modules to make use of new bash scripting I've just learned (having researched to understand the details of phyllisstein's reply). It still installs necessary, lacking modules to the user's PATH, but it is now fully contained within AS (previously it was a Python script that occasionally invoked Applescripts that themselves invoked shell scipts...yeah, I know). Since a vast majority of the Python modules my workflow uses are standard, and the few that are likely to be missing are still fairly basic, I don't think straight installing them is all that bad as a solution until some cleaner, easier, more water-tight solution presents itself.

Well this kerfuffle has led me to rethink the configurator's dependencies installer. I didn't like piping tasks from Python to Applescript to the shell. I also think I had a weak set-up, so I've completely rewritten the config_install-deps script. It is now entirely Applescript. It still checks to see what modules need to be installed, and prompts the user to install the necessary ones. But, it will now actually list the modules to be installed. This is in addition to hopefully being less buggy or more consistently helpful. PLEASE let me know if you run the new configurator (v. 5.2) and things work PROPERLY. I know that typically only bugs are reported, but I would sleep easier knowing it is working as I imagine it will.

Thanks for the small correction. I will say tho, on the larger topic, that I at least could use some guidance on dealing with dependencies. Attempting to wrap the packages in the workflow simply didn't work for me. For whatever reason, relative imports constantly failed. My attempts to help users download required packages to their comp are also hit or miss. The specific problem comes when you rely on highly specific packages for certain tasks. In my case, I MUST use pyzotero, a Python package for interacting with Zotero's API. This is a complex package and I can't avoid the non-standard dependencies. Still a relative noob in Python, I feel underskilled to provide a bug-free workflow that nonetheless relies upon non-standard packages. I have to imagine that I'm not alone in this position. Any thoughts or ideas on creating a water-tight, user-friendly system for dealing with Python dependent workflows are highly welcome.

Well I'm glad it's working fully for you now, and hopefully it will be a great boon to your workflow. Also, if you do come to have feature requests, let me know. I obviously can't make promises, but I'm always interested in making things better.

Well thank you for giving me so much great feedback on small issues that weren't appearing on my machine. That feedback makes the workflow as a whole much stronger.

Okay. do the exact same thing for "feedparser" (instead of pytz).

Okay. Well easy fix. Open Terminal and type "sudo easy_install pytz". Press return. Report the result and then try the exporter.

Did you run the configurator first? That should see that the module pytz isn't downloaded and try to download it. If you didn't config, delete the config files and run z:config. Then see if the dialogs appear, then try the export.

Ok. For whatever reason, the AS dialog boxes where I try to show the icon don't like your machine. But that's fine because its an unnecessary addition. When I went and fixed the action AS config scripts, I forgot about the AS dialogs in this script. So, I went in and added the error routing with these dialog boxes as well. If it can't find the icon, then it will show simple dialogs instead. This should resolve the problem. I've just uploaded v. 5.1 to Packal with the bug fix. Install and let me know.

Can you run the config_install-python-dependencies.py from the Terminal? See what errors it throws?

Argghh.... To be honest, all these Python dependencies are frustrating me. Trying to wrap them into the workflow just isn't working. Honestly, the best solution is to install them on your machine, which is what the first step of the configurator is trying to do. When you run the config script, does a dialog appear that says all Python dependencies are installed? Or what does it say? I think I'm going to give up trying to wrap these modules in the workflow (I can't figure it out), and have people manually install if the configurator doesn't work. But if the config script isnt working, I'd like to know. So for now, re-configure and let me know what the install-python-dependencies script says. From there, I can tell you how to install the two necessary modules manually.

Just updated to version 5.0. New feature is the ability to attach a PDF to an item in your Zotero library using a File Action or a Hotkey. I've updated the ReadMe on my blog with further details. I will also update the main page post.

Luckily, this should only be a problem in larger, more robust workflows. I've found in my ZotQuery workflow that even the attempts to install necessary packages when configuring isn't 100% fail-proof. I recently had to add the feedparser and pytz packages to the workflow itself to kill a bug that a user had. One thing I noticed when doing so was that you can greatly reduce the workflow's size if you clean out all of the Python Source Files before sharing. That effectively reduced the size of my "dependencies" folder by half. So while I would like a cleaner, lighter solution that would allow me to utilize these non-standard packages (in my case, it's the fact that I use one highly specific package to interact with the Zotero API, which itself relies on a number of non-standard packages/modules), I think that being conscious of .pyc files can help alleviate some of the heft.

Ok. I think I've fixed the AS dialog problem. Apparently, AS sometimes won't allow scripts to display dialog boxes on their own. So, I've wrapped all dialogs in tell blocks to the Finder. This should ensure that they appear. I've just updated to Packal (v. 4.8). Try it out and let me know.

I will need to research this "No user interaction allowed" error. This is new to me. However, the other error is fixed. It was a silly mistake on my part (sorry), but the new code is up on Packal (v. 4.7). That should solve the exporting issues for good. As I said, I will see what I can find about the other issue. It appears that something isn't allowing AS dialogs to run. Never seen this before. If anyone has any knowledge on this, I'd love to know.