Proposal: Local curl request caching about neil

[borkdude]

I haven't noticed problems as a user. For a developer, I think we have the token solution. Let's not complicate things if we don't have to: caching is hard.

[borkdude]

Wasn't this problem already addressed by using a GITHUB_TOKEN?

[russmatney]

Yes - the github token takes care of it, if we're ok with every dev creating/using one to run the tests, and similarly if end users run into this, they can also create and set a token themselves (if we document it).

To me, this is a route to not requiring that of neil devs and users.

The actionable thing (if we don't want to go for a local cache) is probably improving the error handling when github 403s b/c of the rate limit.

[russmatney]

This could also speed up the tests somewhat - I'm not sure exactly why they're slow, but if it's b/c of the network requests, this would be a route to getting those to something more reasonable.

But, feel free to close if there's no interest - it's not a pressing need or requirement for neil by any means, was just similar to a problem i'd seen recently, so i thought i'd share.

[russmatney]

sure, seems fine - i appreciate the commitment to keeping the complexity down! hopefully we never have to deal with this

[teodorlu]

I also think it's useful if we discuss end user needs separately from developer needs.

Another way to frame the developer side is that tests are currently:

1. Not possible to run if my network is down
2. Are not idemponent / immutable. API outages or remote API changes or API usage limits can cause flaky tests.

I see caching as one potential solution. Other solutions to "better tests" are probably worth considering too.

Personally - being able to provide a local Github token solves 99 % of my current needs. The remaining 1 % is mostly aesthetics 😄

[russmatney]

It occurred to me that an in-memory cache (dropping the external file bit) would solve the repeated-requests-in-tests problem, because the memory is shared across tests.

I did a quick proof of concept here: russmatney@fb5d718

This allows the tests to grow without adding more request burden - if they all work with (for example) :lib clj-kondo/clj-kondo, the whole suite would only make a handful of requests per run (vs new requests per test).

No worries pressure to pick this up - just an idea/starting point to consider if we ever want something like this. No worries on dropping it for now, just had to get the idea out.

[russmatney]

I'll close this, as it's not a real problem for anyone at the moment. I opened a small docs PR mentioning the env vars in the Contributing section - that might help head off the confusion for new contributors: #129