For instance, if you just have a Python script importing a statistical library, what version are you going to use? Scipy had a pretty nasty change in one of its statistical functions, changing the outcome of significance tests in our project. Depending on which version you happened to have installed it'd give you a positive or negative result.
I would argue that they should use no dependencies to avoid this problem entirely, or download them and include them as source in the project, or at least include a note of which version of a major library they used in a README or comment. I think this is what is often done in practice currently.
Perhaps as you are saying, docker is just a stable way to document this stuff formally. But it is a large moving part that assumes a lot of stuff is still on the internet. What if the docker hub image is removed or dramatically changed? What if that OS package manager no longer exists? It just doesn't seem like our software is getting more longevity, but less. I don't know why we would bring that extra complexity to academic research if the goal is longevity.
Python/C files didn't work in a vacuum. They need dependencies, that is the point of Docker after all.
Capture all necessary dependencies into a single image.
They do if you use the standard library (which for python is quite extensive), and copy any dependencies into your own source, as if they are your own. By "in a vaccum" we can mean if python o is installed, it will work.
> Capture all necessary dependencies
Docker doesn't capture any dependencies. They still exist on the internet. It just captures a list of which ones to download when you build the image.
Do you think software we write now has more longevity than older software that uses make or a shell script?
I can build a docker file from 5 years ago because all the links are dead.