Big Bad Bug - Final uploads

To everyone, and especially Daniel,

Please note I discovered a nasty bug while trying to upload my final entry. I was using Slimjet browser, a Chromium derivative - Windows 10, file format tar.gz made by MobaXterm (a Cygwin derivative).

The issue is this: the upload appeared to work fine. I have had trouble with uploads and archives before, so I downloaded it to test the archive. I found it was corrupt. I retried uploading twice more and they were corrupt. I switched to Internet Explorer and the archive's integrity survived.

Now I have seen this issue twice during the competition. This poor guy is bitten by it: I wouldn't be surprised if there are more to come.

No idea where to start an investigation to stamp this out. For now, spreading awareness seems the best immediate course. Judges, please be gracious if you encounter corrupt final entries during Pyweek 30. Hopefully people provided a repo we can download source and still play 'n judge; or they are reachable somehow, and it can be fixed with Daniel's help.

Maybe there is something more Daniel can do to assist the bug-bitten among us? Thanks for reading. :)

(log in to comment)


I checked both of the .tgz uploads under and they extract and play just fine.

What software are you using to check the archives?



Looks like a tar-gz archives gets decompressed when downloading from the site.

I checked PyWeek30_LateWarp-0.91.tgz. 

Original md5sum is 5d1ec3b706bfd732b0858628c0da645c, size 11 364 405 bytes, file says.
I have downloaded games using pyweek download 30. All right.
But using browser: md5sum b8b10ad9f372add1f76440c33e3db91b, size 11 468 800 bytes. I checked. It is decompressed original archive.

Decompressed tar archives are fine for judging. It is easy to unpack it with tar xf archive.tgz or rename archive.tgz to archive.tar and open it with GUI programs such as 7-zip.
Oh, then the bug is that S3 is sending a Content-Encoding: gzip header, causing the browser to decompress it as it downloads.

By the way, does the PyWeek CLI work for downloading these?

@yarolig Thanks for that tip! "tar tf" does indeed work.
@mauve Cool. I didn't know about the CLI. Trying it the first time.

In MobaXterm/Cygwin I had to: py3 /drives/c/Python37/Lib/site-packages/ download 30

The CLI downloads tar.gz files without decoding them. "tar tzf" and "tar xzf" works as expected.


TIP: Folks who are looking for info on the CLI go to Help, and search "Pyweek CLI".
Hi @mauve.

Regarding the cli downloader, I have an issue to report. While going through the entries, I noticed two teams that have the same project name "Castaway" on the Entries page:

Search the Entries page for "Castaway —" to see them.

The cli downloader apparently downloaded the finals for the former, but not the latter; or a race condition in the downloader clobbered the directory. Which is to say the download directory "castaway" has these files from the former project: 

but not this one from the latter project:

We can still manually download, so it's not a crisis. :)

Filed as
@mauve I tried the CLI and get this error. Any ideas?
requests.exceptions.SSLError: HTTPSConnectionPool(host='', port=443): Max retries exceeded with url: /31/downloads.json (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1076)')))