lit Lit zip packages are broken

From IRC:

<creationix> oh no, I did it again and ran git gc on the lit server forgetting that it collects snapshot trees <creationix> I should really create tags for them so git's GC is aware they are actually used <creationix> what this does is breaks lit make ... for all packages published. <creationix> it uses the snapshot instead of dynamically resolving the dependencies <creationix> we should also have a fallback that dynamically resolves dependencies if the snapshot hash is broken or missing <creationix> this also means installing lit is currently broken since it uses the snapshot tree as part of the bootstrap <creationix> hmm, and the luvi binaries we released recently don't work on linux because my openssl was too old on the host <creationix> so much broken.... :(

This means all previous lit versions no longer have a working zip on the lit server (e.g. https://lit.luvit.io/packages/luvit/lit/v3.5.4.zip) and therefore can't be installed using the method in get-lit.sh, which is a problem (especially combined with problems with luvi's shared openssl in recent versions outlined here).

Not sure what all is needed to fix/band-aid this, but thought I'd make an issue to maybe get the ball rolling.

Mar 07 '19 01:03 squeek502

Thanks for making an issue and sorry I broke stuff. I'm seriously considering re-implementing the lit server at a serverless deployment so I don't need my custom vps that I obviously can't be trusted to be the sysadmin for with all my other responsibilities.

One thing I really liked about lit serve was anyone could do it and get an instant caching proxy server for packages and/or a private registry. This is especially good when compared to the years of pain people had trying to do the same with npm.

I worry if we switch to serverless for the official registry then bugs in lit serve will be even less likely to get fixed. What do you all think?

The data storage requirements are pretty minimal. It's just a bunch of content-addressable objects (key is literally sha1 of value) and a few name to hash labels. Any key value storage would work well, even ones with immutable values (write once keys). Right now it's a folder on my vps that's written out as a git repository that I manually push to github for offsite backup. This is where the problem came in because git sometimes runs gc when doing other commands and according to git, all the snapshot trees were orphans!

Mar 12 '19 15:03 creationix

One other thing I noticed while looking into this is that the server could potentially resolve missing snapshots as well here. Could basically do the same fix as #249 but on the server side. Would that be a good thing to have?

Mar 12 '19 21:03 squeek502

I guess this is for zip generation. It would probably be good to have as a fallback.

Mar 12 '19 23:03 creationix

I guess this is for zip generation. It would probably be good to have as a fallback.

https://github.com/luvit/lit/pull/250

Mar 13 '19 01:03 squeek502