[racket] Worried about the new package manager not storing each version of a package

Jay McCarthy writes:

 > The users can do something. They can save their old version before
 > they upgrade and not continue if there is a problem. The package
 > system definitely supports "trials" like this, because it's easy to
 > locate the files you downloaded for the package. I don't recommend
 > blind updates in any package system.

I wouldn't qualify as "easy" any operation that requires manual file
system manipulation by the user, who moreover has to understand the
file layout of package installations first. I'll bet that in practice
nobody will do what you describe except in an emergency.

Though I can't claim much Racket experience, I have used (and suffered
from) lots of package management systems, either at a language level
(Python's PyPI, Java's Maven Central, Clojure's Clojars) or at a
system level (various Linux distributions). My observation is that
each package management system that survives for a while either allows
parallel installation of multiple versions, or pushes users to
integrate version numbers into the package names as a workaround. In
my environment, that latter case covers mostly Debian, where it is
often a real pain. I really appreciate Homebrew on my Mac, which lets
me install different versions in parallel.

What I expect from a language-level package manager is the ability to
define at the project level which exact versions of each dependency I
want to use. With the Racket package manager making a distinction
between "version" and "release", that would in fact be "release"
rather than "version".

Note that this is not just a matter of compatibility between package
versions, it's also a matter of debugging and of documentation. If I
get a bug report from a user saying that my package no longer works
with the latest release of one of my dependencies, then I want to be
able to set up quickly a test project using that release for
debugging, while of course keeping the known-to-be-good release for my
normal work.

As for documentation, it can be important in certain situations to
know exactly which releases of all packages were used in a given
computation, and to be able to re-create that setup for verification.
Such a traceability is a cornerstone of the "reproducible research"
movement that aims to make computational science more reliable. With
research software typically evolving rapidly, it is often impossible
for scientists to reproduce their own results from a year ago, meaning
that they can never be sure they didn't use a buggy version of some
library.

 > If a developer does not want to maintain or host a package, then I do
 > not feel we have the right to obligate them to do so or to allow us
 > to. If they license their code in a compatible way, however, a
 > passionate user could take it over.

I think it's a good idea to keep local installation management and
hosting/distributing packages apart. They are different problems that
require different solutions. A package manager should provide version
handling for those packages for which older releases remain available,
which I expect to be the majority of packages.

One option for package archiving that I haven't seen used much but
which I think is worth exploring is the use of DOIs. Right now, anyone
who wants to archive a package for eternity (more precisely its
cyberspace approximation) can just dump it on Figshare and get a DOI
in return, which Figshare promises to maintain forever. Figshare isn't
a good place for software yet because they only provide CC licenses,
but that's something they are working on for the future.

Konrad.