Hacker News Reader

Comment by nihiven | Hacker News Reader

This is really cool. It seems very 'pure' in comparison to what my code history will look like. In 2040, a lot of my code will show how I used a bunch of libraries and frameworks that nobody uses 'these days'. This doesn't seem good or bad, just a reflection of the times.

View on HN

And unless you put in the effort to archive those dependencies yourself, nobody may be able to truly read or build your code anyway.

Today’s trendy development practices are shockingly ephemeral and fragile. Very little of today’s projects would survive one decade left fallow, let alone four.

A few years back my office threw away a PC running Windows XP with no service packs. It was left in a closet for many years just in case we had to fix a bug in some safety critical code.

A few years ago we tried to rebuild some safety critical code from sometime back and were unable to because the certificates had expired and so the machine that can build the source code refused to connect to our version control system.

This is why I really like Debians policy of being self-contained, that everything in Debian is built from sources that are in the Debian system.

It takes a lot more effort to package stuff, since you can't just download your dependencies from the internet. But you also create something that isn't as ephemeral.

Since you mention it, I recall that it's the same thing in OpenBSD: their policy is "base builds base."

> Today’s trendy development practices are shockingly ephemeral and fragile

My fellow human, you have just nailed what is wrong with today's software.

Or stated a tautology. The trendy is almost by definition ephemeral and fragile. Otherwise we'd call it timeless!

> And unless you put in the effort to archive those dependencies yourself

go makes this extremely easy to do

https://go.dev/ref/mod#go-mod-vendor

rust tool chain also includes a vendor dependency process

https://doc.rust-lang.org/cargo/commands/cargo-vendor.html

Do you use this and check in vendored code? I don't, maybe I should

Reading this thread makes me think about archiving my code too. I have backups of my project folders going back to the 90s when I started programming. But I often delete node_modules and other build artifacts before archiving because that stuff takes up so much space.

But maybe it’s worth going through and actively and explicitly downloading all those dependencies too. Who knows when npm will get hacked again, or old package versions will get yanked. Disk space is cheap. I’ve written a lot of code over the years. It would be nice to know it all still runs.

  > Very little of today’s projects would survive one decade left fallow, let alone four.

I hate to break it to you. 2040 is less than half as distant as you think it is.

I want off this ride.

It will be over sooner than you think it will be.

I think that's somewhat the curse of technology. It's so hard to make anything from scratch. How do you get metallurgy working without already having metals? How do you get electricity running without an outlet, or at least powerful, easily sourced magnets?

Thinking about the "dependency tree" for any modern convenience is truly staggering. I can't even start to think about how you can make a factory without first having a factory.

Checking dependencies into VCS should be more common as with yarn PnP and such.

all these `pip install` and `npm install` will be useless

They already are, if your internet connection has a hiccup or worse.

They already are, if something has been hijacked and is now malicious.

They already are, if you need to install something offline somewhere.

They already are.

Even before... Trying to compile archived versions of the python 2.7 runtime on recent Linux distributions is an exercise in frustration. Thank god for the gentle souls that keep putting out lightly updated compilable 2.7 python runtimes, your efforts haven't gone unnoticed.

I have a directory full of prebuilt wheels for the entire dependency chains of several python applications I use. All you need to do is tell python to build all the wheels and save them to X directory, and point it back at that directory for installing. In particular on Termux, there's a number of rarely-used python programs that have native dependencies, so I store them on my network drive to free up storage on my tablet. I have a similar setup for doing stuff on Colab. It's entirely possible to use python/pip in an offline environment, as long as you've planned for it ahead of time; all you need is pip and possibly wheel, and the correct version of python.

not sure if node has its own vendor process now

But languages like go and rust have had the ability to “vendor dependencies” for awhile now.

Don’t need an active internet connection. Just need to have the toolchain.

Node predates npm. All node does is look for dependencies in the nearest node_modules directory. (And all npm does is download dependencies into that folder). So you can simply archive / check in your node_modules directory if you want to. I think there’s tools to help out and make sure the dependency versions are all pinned. (npm shrink-wrap and friends)

Reply on news.ycombinator.com