←back to thread

272 points abdisalan | 1 comments | | HN request time: 0s | source
Show context
Klonoar ◴[] No.42175423[source]
You know, I ran into something similar recently with a static site engine (Zola). Was moving to a new host and figured I'd just copy and run the binary, only to have it fail due to linking OpenSSL. I had customized the internals years ago and stupidly never committed it anywhere, and attempting to build it fresh ran into issues with yanked crates.

Since it's just a binary though, I wound up grabbing the OpenSSL from the old box and patching the binary to just point to that instead. Thing runs fine after that.

This is all, of course, still totally stupid - but I did find myself thinking how much worse comparable events in JS have been for me over the years. What would have been easily an entire afternoon ended up taking 15 minutes - and a chunk of that was just double checking commands I'd long forgotten.

replies(3): >>42175501 #>>42175582 #>>42175642 #
ikawe ◴[] No.42175582[source]
What’s the issue with yanked crates? It should still build from your lockfile, even if it contains yanked crates.
replies(1): >>42181118 #
swiftcoder ◴[] No.42181118[source]
Assuming you actually committed the lockfile...
replies(1): >>42181489 #
mst ◴[] No.42181489{3}[source]
Never underestimate the potential of past-you to have accidentally missed a tiny but essential step in a way that won't have made a noticeable difference at the time, yeah.
replies(2): >>42183233 #>>42192391 #
1. swiftcoder ◴[] No.42192391{4}[source]
I think the other foot-gun here is that the official recommendation is that library crates not check-in their lockfile (I assume because that prevents downstream crates from freely taking updates to common dependencies).

This has the unfortunate side-effect that while downstream apps might still build, the library itself (and any examples in the library repo) may not compile after some time...