re: the build cache - I thought I read that you ju...
# general
c
re: the build cache - I thought I read that you just a fairly basic HTTP server
a
@curved-vase-73456 was telling me at scale by the bay that the specific sequence of PUTs and GETs wasn't specified anywhere except in the pants source code -- i believe he was saying he did just stand up a django app, there just wasn't really an API specification.
c
Remote cache has this description in the docs: <there was a bad link>
🙏 1
c
looks like greek to me
c
The authorization method though is a Basic Auth only with a pretty unique internal mechanism on request calls and there's no way to set it up for any existing service on the fly you have to write middleware to connect to Amazon s3 or Google Storage or whatever else
☝️ 1
a
ah, sorry, i forgot about that important part
c
this is what I see from the link above
c
Oops
a
thanks for finding it, i should have known that link
c
No worries, ty for remembering our conversation and pinging me 😊
c
how hard is it to switch between using a shared cache to a local one - say for working on a plane
a
the local cache and the remote cache should have the exact same data, ish
(and there are some bugs for e.g. working on a plane which we need to fix, mostly around python stuff which is getting revamped)
but if you do e.g.
./pants compile ::
or something and then lose internet, i believe the local cache should have been populated from before and you can continue to work
if there are errors for some reason you can just set the remote cache urls to an empty list, i forget the exact option but i am pretty sure that workflow is supported because engineers have raised tickets internally when offline mode isn't working
c
nice
a
to put it another way, pants will as of now populate the local cache with any artifacts it can get from the remote cache, and build the ones it can't, and it will use the local cached artifact from then on
c
similar to a local ivy/coursier cache -> caching nexus/artifactor -> public maven/ivy repos