Giters

elm-lang / elm-package

Command line tool to share Elm libraries

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Evidence for retry in package managers

evancz opened this issue · comments

commented

Thanks to @garbas for the following exploration, taken directly from #163 (comment). As a side note, new issues are always preferred to adding on to old things. Folks should just try to write something clear and concise, and I will do the meta analysis to connect the topics.

I'd like to cast my vote on having a retry policy in elm-package when downloading.

The following language specific package managers I checked have retry logic builtin:

  • pip
  • stack
  • yarn
  • bundle - has a --retry option
  • apt-get does not have to any retry logic, but aptitude has it.
  • rpm does not have retry logic but yum have it.

It looks quite common to retry when a connection error happens. And there might be many reasons why connection can fail, which has nothing to do with code and I see no better way but to retry.

commented

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

commented

@evancz thank you for moving this into a separate issue.

Now that I got preliminary 👍 from --retry functionality, I dig deeper on how (timeout, when to retry, how many retries, ...) retries are done in different package managers.

I'll start with pip since I'm most familiar with it

pip

Options with their defaults which control how packages get downloaded

  • retries [Default: 5] Maximum number of retries each connection should attempt.
  • there is a backoff_factor configured to 0.25. This means that first timeout is going to be 0.25s and next one 0.5s and next 1s.
  • a retry happens when the following status codes happen -> 413, 429, 503