Jump to content

Alleyoop: Update Alfred Workflows


Recommended Posts

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?

Link to post
  • Replies 168
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Note from Andrew: While this is a convenient method for updating workflows, I cannot endorse the use of it unless you are fully aware of the security implications of blanket updating all of your workf

As posted at the top of this thread - While this is a convenient method for updating workflows, I cannot endorse the use of it unless you are fully aware of the security implications of blanket updati

That is awesome, will include it into mine asap. One neat thing would be to have another command "ooplist" or so, to see which workflows are oop-enabled.

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?

Link to post

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.

 

Link to post

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.

Link to post

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.

Link to post

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 :unsure: ) — 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)?

Link to post

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). :(

Link to post

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)
Link to post

Odd. :unsure:

 

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)
Link to post

Getting closer. :huh:

 

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.

Link to post

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.

Link to post

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.

Link to post

Great stuff, seems to be working nicely now with those UTF-8 filenames. B) 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? :D

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

Edited by CarlosNZ
Link to post

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 account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...