search

tvo / rapid

Commandline client for Spring rapid downloading system
Other
7 stars 6 forks source link

Don't die if a repo has no versions.gz #42

Closed db81 closed 9 years ago

db81 commented 9 years ago

pr-downloader stores repos.gz in ~/.spring/rapid/repos.springrts.com/repos.gz and rapid tries to access ~/.spring/rapid/repos.springrts.com/versions.gz which doesn't exist. The change makes rapid treat reos.springrts.com as an offline repo with no packages. This is useful because it allows rapid to coexist with pr-downloader.

I need it because I want to try using rapid to download mods in weblobby while still using pr-downloader for maps and engines, after @ForbodingAngel's praise toward rapid finally convinced me.

abma commented 9 years ago

don't revive dead horses. rapid is deprecated, use/fix/improve pr-downloader instead.

ForbodingAngel commented 9 years ago

Then make pr-downloader stop failing?

PR-Downloader's constant failure on downloading new games the first and sometimes second time is the whole reason for this. Unfortunately it is behavior that is incredibly hard to replicate and probably has to do with conditions outside of pr-downloader, but in some cases it is pr-downloader failing to update it's repositories on windows (PR always works on linux as far as I'm aware).

It's hard enough to replicate that I pretty much can't on any of my machines, but among new users it is commonplace. It isn't just steam users either.

abma commented 9 years ago

Where is the bug report about this?

db81 commented 9 years ago

The story behind this is that I wanted to try rapid partly out of curiosity, partly due to forb's praise, partly because it has interesting features (listing tags, cleaning packages, creating sdds). The fix that made it work together with pr-d was trivial and it seemed to work fine despite being deprecated, so I decided to post the PR on the off chance that @tvo still watches it. Which he doesn't, so I'm closing the PR.

Regarding bugs in pr-d, one that I know is that sometimes it can fail to download a package and leaves an empty .sdp in ~/.spring/packages and then it thinks it already has it and never tries to redownload. Sorry for never making an issue about this one.

As for the rest, it's too incoherent to work with, like it seems that sometimes the download gets corrupted and you have to nuke ~/.spring/pool to fix it, but it never happened to me and it's very rare and no one can replicate it; sometimes it fails to update the package list (maybe?) and doesn't download recently released versions and IIRC nuking ~/.spring/rapid fixes that. Then there's the issues people complain to forb about like the first download failing that no one can replicate either.

@ForbodingAngel: I managed to replicate the bug with spaces in arguments on my laptop, and it looks like a bug in the lib swl uses to run commands. So far it makes no sense why using rapid or pr-d would change anything at all.