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. ____________________ Racket Users list: http://lists.racket-lang.org/users
