[whartung]

  > For software, side project or not, it should probably come with dependency configurations (granted, in early 2000s this isn't as mature as it is today) and some tests.

These may or may not help. Things have certainly changed in the past several years, but if we have learned anything, the "infinite memory of the internet" is anything but. Dependencies vanish and die all the time. So, while you may have a list of dependencies, if you don't have those actual dependencies locally with you, you may be out of luck. Even if the actual project still exists, the older versions you depend on may not.

I can't speak to others, but if you were to actively shelve a Java project, and were using Maven or relying on its infrastructure, I would clean out your local repository cache, rebuild and test the project, then snapshot the project directory and the repository cache. At least then you might have a solid chance of resuscitating the project later on if you needed too.

[spockz]

Or, point maven to a directory in your repo (`-DlocalRepository`) and include it in your git with lfs. Best of both worlds. Get to use dependency management and always have your dependencies around.

[KronisLV]

> These may or may not help. Things have certainly changed in the past several years, but if we have learned anything, the "infinite memory of the internet" is anything but. Dependencies vanish and die all the time. So, while you may have a list of dependencies, if you don't have those actual dependencies locally with you, you may be out of luck. Even if the actual project still exists, the older versions you depend on may not.

I say this problem impacts most of the development stacks out there, whenever you're dealing with a package manager:

  - Node and Javascript have npm
  - Python has pip
  - .NET has NuGet
  - Java has Maven/Gradle
  - PHP has Composer
  - Ruby has gem

And all of those have packages that could technically disappear, or you could have network issues and so on (when I build my container images, I sometimes even have apt fail, though very rarely). I think a safe bet is to run your own package proxy, like Sonatype Nexus: https://www.sonatype.com/products/nexus-repository (there's also JFrog Artifactory in this space, probably others too: https://jfrog.com/artifactory/)

This can improve build speeds because you refer to your own server for getting packages, the proxy will also pull packages that it doesn't have automatically, there are no rate limits to deal with (e.g. DockerHub pull limits vs the image being pulled once and stored in Nexus, unless changed) and you can also pretty easily see just how much stuff you're relying on.

The next step is to also use this server for publishing your own packages, which is suddenly easier - you can manage your own accounts, with nobody to tell you what you can/can't upload and how: you literally have all of the storage on the server at your disposal, redeploy as often as you want.

The only real downside to this is that you are indeed self-hosting it: you need updates, storage and all that. Well, maybe there's also the issue that using custom repositories downright sucks in some stacks - while npm supports something like --registry, I distinctly recall Ruby being a total pain in this regard in a container context (something about Bundler configuration, since it doesn't seem to support a command line parameter): https://help.sonatype.com/repomanager3/nexus-repository-admi...

[whartung]

In a related matter it behooves open projects to do a very clean build before they do a release.

By that I simply mean they should take a source distribution of their project and perform a build with their repository caches cleared to ensure the project actually still builds in the wild.

Dependencies can silently vanish behind the facade of a local proxy or cache.