3 ms·

Would you really want to roll your own exponential backoff w/jitter for every project though? It's not the easiest to get right, and since you're looping in a s

Would you really want to roll your own exponential backoff w/jitter for every project though? It's not the easiest to get right, and since you're looping in a somewhat complicated way, it's definitely prone to accidental infinite loops in my experience. Retrying seems perfect for a library to me. For instance, Haskell has a popular retry library https://hackage.haskell.org/package/retry-0.8.1.0/docs/Control-Retry.html https://hackage.haskell.org/package/retry-0.8.1.0/docs/Contr... and I wouldn't consider it bad to just bring it in. Is this more symptom of Python deps being "riskier" than Haskell deps due to types or versioning or something?

cjfd 7y ago
Any dependency is also a risk. What if the next version does not just contain a nice feature that you want but also a nasty and subtle bug that you notice only later? Also, maintenance of a small library is by no means guaranteed to remain at the same level of quality. Generally, one is much safer with larger and more serious libraries. I would say one should just have dependencies that provide some rather serious set of features that would cost a lot of time to implement oneself.
guitarbill 7y ago
Not at all, I think they just have some notion that npm = bad and npm = (small) deps, so (small) deps = bad. I agree, it's harder to get right that it seems from first glance. The number of implementations I've seen with broken or not-honoured timeouts... Python also had a retrying library; apparently it's no longer maintained. I've used the tenacity "fork", which has also evolved/introduced some great features like combinable and chainable wait/backoff.
- oefrha 7y ago
  > Not at all, I think they just have some notion that npm = bad and npm = (small) deps, so (small) deps = bad. No, I don’t have that notion. Apparently not every package on npm is small or trivial, but the abuse of trivial packages is most well-known and disastrous in the npm ecosystem. Edit: My god, iOS autowrong is all the rage today.
oefrha 7y ago
This library posted here is only ~150 loc without docstrings, and it’s more complicated than my typical equivalent decorator factory with basically the same features, sans logging. I just don’t find this tricky. If only every problem I need to solve is as simple as this one. > Is this more symptom of Python deps being "riskier" than Haskell deps due to types or versioning or something? No, it’s a distaste for tons of small third-party packages that could easily be done in place. If anything I found Haskell deps more prone to breakage with upgrades compared to Python deps (given my limited experience with Haskell), at least with the set of popular packages I tend to use. Part of that is Python packages tend to not depend on a ton of other packages.
- whateveracct 7y ago
  By "breakage with upgrades" do you mean bugs introduced due to compiler/library bumps or just PVP constraint violations?
  - oefrha 7y ago
    The latter — not necessarily PVP constraint violations though, but rather dependency hell situations. One example that pops to mind: packaging git-annex for Homebrew was always “great fun” until we settled on resolving with LTS Haskell (IIRC).

cjfd 7y ago

Any dependency is also a risk. What if the next version does not just contain a nice feature that you want but also a nasty and subtle bug that you notice only later? Also, maintenance of a small library is by no means guaranteed to remain at the same level of quality. Generally, one is much safer with larger and more serious libraries. I would say one should just have dependencies that provide some rather serious set of features that would cost a lot of time to implement oneself.

guitarbill 7y ago

Not at all, I think they just have some notion that npm = bad and npm = (small) deps, so (small) deps = bad. I agree, it's harder to get right that it seems from first glance. The number of implementations I've seen with broken or not-honoured timeouts... Python also had a retrying library; apparently it's no longer maintained. I've used the tenacity "fork", which has also evolved/introduced some great features like combinable and chainable wait/backoff.

oefrha 7y ago
> Not at all, I think they just have some notion that npm = bad and npm = (small) deps, so (small) deps = bad. No, I don’t have that notion. Apparently not every package on npm is small or trivial, but the abuse of trivial packages is most well-known and disastrous in the npm ecosystem. Edit: My god, iOS autowrong is all the rage today.

oefrha 7y ago

This library posted here is only ~150 loc without docstrings, and it’s more complicated than my typical equivalent decorator factory with basically the same features, sans logging. I just don’t find this tricky. If only every problem I need to solve is as simple as this one. > Is this more symptom of Python deps being "riskier" than Haskell deps due to types or versioning or something? No, it’s a distaste for tons of small third-party packages that could easily be done in place. If anything I found Haskell deps more prone to breakage with upgrades compared to Python deps (given my limited experience with Haskell), at least with the set of popular packages I tend to use. Part of that is Python packages tend to not depend on a ton of other packages.

whateveracct 7y ago
By "breakage with upgrades" do you mean bugs introduced due to compiler/library bumps or just PVP constraint violations?
- oefrha 7y ago
  The latter — not necessarily PVP constraint violations though, but rather dependency hell situations. One example that pops to mind: packaging git-annex for Homebrew was always “great fun” until we settled on resolving with LTS Haskell (IIRC).