Alleyoop: Update Alfred Workflows

[CarlosNZ]

Hey, I'm just trying this out with one of my workflows, and the update process is silently failing.

 

Here is the output from the 'act.py' script:

Traceback (most recent call last):
  File "act.py", line 55, in <module>
    act()
  File "act.py", line 31, in act
    do_download(remote, target_path)
  File "act.py", line 20, in do_download
    z.extractall(target)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/zipfile.py", line 962, in extractall
    self.extract(zipinfo, path, pwd)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/zipfile.py", line 950, in extract
    return self._extract_member(member, path, pwd)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/zipfile.py", line 979, in _extract_member
    targetpath = os.path.join(targetpath, member.filename)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.py", line 71, in join
    path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xcc in position 9: ordinal not in range(128)

Any thoughts?

[phyllisstein]

Hey, I'm just trying this out with one of my workflows, and the update process is silently failing.

 

Here is the output from the 'act.py' script:

Traceback (most recent call last):
  File "act.py", line 55, in <module>
    act()
  File "act.py", line 31, in act
    do_download(remote, target_path)
  File "act.py", line 20, in do_download
    z.extractall(target)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/zipfile.py", line 962, in extractall
    self.extract(zipinfo, path, pwd)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/zipfile.py", line 950, in extract
    return self._extract_member(member, path, pwd)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/zipfile.py", line 979, in _extract_member
    targetpath = os.path.join(targetpath, member.filename)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.py", line 71, in join
    path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xcc in position 9: ordinal not in range(128)

Any thoughts?

Does your workflow name or path have a "`" accent in it somewhere?

[CarlosNZ]

Does your workflow name or path have a "`" accent in it somewhere?

Nope, not locally. The download filename has a space in it though, which puts a '%20' in the uri. Could that be a problem?

Specifically, the whole remote json file is:

{
    "version": 1.6,
    "download_uri": "http://cl.ly/NwuW/download/TimeZones%20v1.6.alfredworkflow",
    "description": "Now supports one-off custom lookups. See changelog for full details."
}

and is located at: http://alfred.philosophicalzombie.net/workflow_updates/timezones.json if that helps.

 

Let me know if you'd like me to PM you a link to the (unreleased) workflow version I'm trying to use to test the update.

Cheers.

 

[phyllisstein]

That's terribly strange. It'd be great if I could take a look at the workflow; it looks from the traceback it's finding a non-ASCII character in one of the files in the zip, maybe, but I'm not totally sure how to fix that.

[iEnno]

Great work, implemented in all of my workflows. Thumbs up!

[CarlosNZ]

That's terribly strange. It'd be great if I could take a look at the workflow; it looks from the traceback it's finding a non-ASCII character in one of the files in the zip, maybe, but I'm not totally sure how to fix that.

A few of the pngs in the flags folder have non-ASCII characters in the filename.

[phyllisstein]

A few of the pngs in the flags folder have non-ASCII characters in the filename.

Hah, that's just where I was checking. That's likely to be the problem. And since it's internal to the module and hidden in the zip file, I don't think I can just pass it through to the UTF-8 encoder/decoder. You may need to rename them, but that's not really an ideal solution. I just pushed an update that may help—give it a shot and see if it works any better.

[hzlzh]

Hi, check this API to see if you can use.

http://www.alfredforum.com/topic/1666-workflows-list-now-support-json-api-output/

[CarlosNZ]

Hah, that's just where I was checking. That's likely to be the problem. And since it's internal to the module and hidden in the zip file, I don't think I can just pass it through to the UTF-8 encoder/decoder. You may need to rename them, but that's not really an ideal solution. I just pushed an update that may help—give it a shot and see if it works any better.

Nah, still no go.

 

Here's the output now:

Traceback (most recent call last):
  File "act.py", line 60, in <module>
    act()
  File "act.py", line 36, in act
    do_download(remote, target_path)
  File "act.py", line 20, in do_download
    g.write(r.request.content)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/codecs.py", line 691, in write
    return self.writer.write(data)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/codecs.py", line 351, in write
    data, consumed = self.encode(object, self.errors)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xa9 in position 14: ordinal not in range(128)

Yeah, it would be bit of a pain to have to rename the files, since they're named so that they match the country names that Google returns exactly. I guess I could run the Google country names through some kind of ASCII-fier (I think iconv will do it), but that's not an ideal solution.

 

Just a thought (and forgive me if it's a stupid one — I don't know much about Python ) — you seem to be using a python zip module; would it be possible/convenient/helpful to just call OS X's built-in zip utility (command line: zip)?

[phyllisstein]

I could try that, but communicating with the zip process might be even more of an annoyance. I just pushed one more update; would you mind trying that as well? Meanwhile I'll look into using zip.

[CarlosNZ]

That latest download still has "v1.6" in the json file. Not sure if it's the same version, or if you just forgot to update the internal json file in 1.7. If it's the latter, then it's still not working (same error log too).

[phyllisstein]

Whoops, dumb. Changed everything but the actual downloadable file. It should be there now.

[CarlosNZ]

Pretty much the same thing, I'm afraid:

Traceback (most recent call last):
  File "act.py", line 60, in <module>
    act()
  File "act.py", line 36, in act
    do_download(remote, target_path)
  File "act.py", line 20, in do_download
    g.write(r.request.content)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/codecs.py", line 691, in write
    return self.writer.write(data)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/codecs.py", line 351, in write
    data, consumed = self.encode(object, self.errors)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xa9 in position 14: ordinal not in range(128)

[phyllisstein]

Hm, it doubly shouldn't be doing that because codecs isn't in the file anymore and there's nothing on line 20. I just redid the upload by hand in case my rsync daemon is acting up—one more thing to check!—so try http://alfred.daniel.sh/Workflows/Alleyoop.alfredworkflow

[CarlosNZ]

Odd.

 

Basically the same in the latest:

Traceback (most recent call last):
  File "act.py", line 59, in <module>
    act()
  File "act.py", line 35, in act
    do_download(remote, target_path)
  File "act.py", line 24, in do_download
    z.extractall(target)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/zipfile.py", line 962, in extractall
    self.extract(zipinfo, path, pwd)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/zipfile.py", line 950, in extract
    return self._extract_member(member, path, pwd)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/zipfile.py", line 979, in _extract_member
    targetpath = os.path.join(targetpath, member.filename)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.py", line 71, in join
    path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xcc in position 9: ordinal not in range(128)

[phyllisstein]

Hm. I've changed it to use the built-in unzip utility (I think), but I now can't do much error-checking with it. See if you have any luck, though.

[CarlosNZ]

Getting closer.

 

I ran it normal, got "All updates completed". Pretty good, but I checked and the workflow wasn't actually updated. Ran it again with error logging, and this:

checkdir:  cannot create extraction directory:  "/Users/Carl/Library/Application Support/Alfred 2/Alfred.alfredpreferences/workflows/user.workflow.C9701075-D8DD-4A86-BDAC-35D6CA0EABE5"
All updates complete.

So, if that's the output from the "unzip" command, then it's probably just a matter of finding the right flags. Maybe "-o" (overwrite), but not sure if that's just for files.

[phyllisstein]

I just uploaded a new version that ran successfully from the Python interpreter on the file you sent me. It still uses the zipfile module, but skips the open() call that may have been gumming up the works. See if you have any luck.

[CarlosNZ]

D'oh!

Traceback (most recent call last):
  File "act.py", line 61, in <module>
    act()
  File "act.py", line 50, in act
    do_download(remote, target_path)
  File "act.py", line 27, in do_download
    z.extractall(target)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/zipfile.py", line 962, in extractall
    self.extract(zipinfo, path, pwd)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/zipfile.py", line 950, in extract
    return self._extract_member(member, path, pwd)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/zipfile.py", line 979, in _extract_member
    targetpath = os.path.join(targetpath, member.filename)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.py", line 71, in join
    path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xcc in position 9: ordinal not in range(128)

Now I really must go to sleep now. FWIW, it shouldn't be a huge deal to make my filenames ASCII compliant. I've figured what I'd need to do. So if this is causing you too much grief at the moment, I'm happy to go down that road. But then again, I'm sure there'll be others down the road who have this issue too.

 

I'll check back here in the morn and see what you reckon is the best option for now. Cheers.

[phyllisstein]

Alright, the latest version is tested and working with your workflow. Turns out the problem was with alp's args function, which doesn't play nice with zipfile. Something to figure out later; the temporary fix should do fine for now.

[DJay]

Strange checking for updates show v1.95 of alleyoop but doesn't download.  

[Captain Picard]

Strange checking for updates show v1.95 of alleyoop but doesn't download.  

 

It is in the JSON, I think he accidentally put 1.95 instead of 2.0.

[lmartins]

Really nice, at this point im already struggling a bit to keep workflows updated, this make it a breeze.

[phyllisstein]

Strange checking for updates show v1.95 of alleyoop but doesn't download.  

 

 

It is in the JSON, I think he accidentally put 1.95 instead of 2.0.

 

I was able to see the problem and fix it this time, but for future reference, "it doesn't do this" doesn't give me a lot to go on when something goes wrong. There's a post earlier in this thread about what information I need to actually look into and fix problems.

[CarlosNZ]

Great stuff, seems to be working nicely now with those UTF-8 filenames. Well done!

 

Couple of comments (growing to four with edits):

1. I can't remember who mentioned it earlier, but I can confirm that the updates work fine via a bit.ly shortlink. Just remember to link it to the direct download URL, not just the download page.
2. I notice that the update process doesn't delete extraneous files. So if I release an update that does away with a number of files, or if I just rename them, the old versions will be left in the workflow folder. Maybe do a "delete all" from the workflow folder before extracting the zip? And just for safety, send it to the trash rather than completely deleting it. (Even better, maybe zip the existing workflow into a .alfredworkflow file, then send that to the trash - that way a version rollback (as I mentioned earlier) would be really simple for the user)
3. Because checking every workflow against its online update file takes a good few seconds (at least on my crummy connection), it's a bit of a pain to have to wait with Alfred in front and you can't do anything else. Might I suggest a "oop check" keyword that runs an update check in the background, and then posts a notification if there is (or isn't) any updates. Then, we can do the actual update ("oop") knowing that it'll actually be worthwhile.
4. And, oh, I gotta ask - where does the name "Alleyoop" come from?

But well done, everything seems to be working nicely now. Cheers.

Edited April 1, 2013 by CarlosNZ