Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Retry package downloads #279

Closed
snoyberg opened this issue Jun 11, 2015 · 1 comment
Closed

Retry package downloads #279

snoyberg opened this issue Jun 11, 2015 · 1 comment
Assignees
@DanBurton
Milestone
P1: Must

Comments

@snoyberg
Copy link
Contributor

Related to this blog post, @radix commented:

Python's pip package manager also doesn't retry, and I don't really understand why not. (this is one of the most common reasons for a travis job to fail for me, on my Python projects). It seems to me some conservative number of retries should definitely be done, say, 3.

Adding retry logic on download shouldn't be difficult, and ideally would be done with some kind of a config option to control the number of retries (and possibly the delay between them).
@snoyberg snoyberg modified the milestones: First stable release (0.1.0.0?), Later improvements Jun 11, 2015
@snoyberg snoyberg self-assigned this Jun 15, 2015
@snoyberg snoyberg modified the milestones: First stable release (0.1.0.0?), Later improvements Jun 15, 2015
@snoyberg snoyberg modified the milestones: Later improvements, First stable release (0.1.0.0?) Jun 15, 2015
@snoyberg snoyberg removed their assignment Jun 15, 2015
@snoyberg snoyberg modified the milestones: 0.2.0.0, Later improvements Jun 16, 2015
@DanBurton DanBurton added the ready label Jul 8, 2015
DanBurton added a commit that referenced this issue Jul 8, 2015
@DanBurton
#279 Add retries (default 3) to verifiedDownload
940cd19
@DanBurton
Copy link
Contributor

verifiedDownload now retries a given number of times (with no delay) when it gets an HttpException. Future work: use Control.Retry.

Something to note is that, due to this change, the progressSink might be run multiple times. Any code that uses verifiedDownload with a progressSink should make sure that the sink will behave correctly in the case of a partial run followed by a retry. (e.g. the sink should initialize and keep its own state, rather than relying on outside state, when possible.)

dysinger added a commit that referenced this issue Jul 8, 2015
@dysinger
Merge branch 'master' into 401-docker-images
0871dae 
* master:
  #279 Add retries (default 3) to verifiedDownload
  Upper limit on number of flag combinations to test #543
  Flip order of build and test/bench opts parser
  Move `boptsCoverage` and `boptsNoTests` to `TestOpts`
  Replace `boptsAdditionalArgs` with fields in `FinalAction`
  Add benchmark and test options to FinalAction
  Implement `stack bench --benchmark-arguments`
  Fix #537
  Targets outside of root dir don't build (fixes #366)
  Add changelog for #517
  Add --no-run-tests parameter to stack test.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@DanBurton DanBurton

Labels
None yet
Projects
None yet
Milestone
P1: Must
Development

No branches or pull requests
2 participants
@snoyberg @DanBurton