The bug was an induced failure in the http server, to test retry
support, triggered another run of half of the synchronization
protocol, leading to a stuck state.
When a module is currently installed as bytecode, but without
corresponding source and without a "info.rkt" specification that
bytecode should be preserved without source, then `raco pkg` should
not count that module bytecode as a conflict (since `raco setup`
will remove it).
When a package "p" is clone-linked and the repo for "p" changes to be
a multi-package repository (e.g., with "p-lib", "p-doc", and "p"), a
`raco update` would get confused. Unofrtunately, a plain `raco pkg
update p` can't work in that case, because the clone link would still
be a pathless repo URL; the repairs make `raco pkg update --lookup
--clone ..../p` work as is should.
Related: fix inference of package names in the early check for whether
a package is installed.
If the clone directory's checkout includes a target commit, then
use the clone directory directly for staging (i.e., for checking
dependencies and collisions). That way, changes made locally are
used for metadata checks.
The implemented default for `raco pkg update` actually depended on the
way that a package is installed, and it's difficult to reason about or
to implement the default that is suggested by the documentation.
Meanwhile, `search-ask` seems the most sensible always in interactive
mode (now that we have a way to specify batch mode).
Packages that are installed as other than a link are not meant to be
edited, but work can get lost if a package is edited and then removed
or updated. Avoid that work loss by moving removed or updated packages
to a trash folder.
By default, the trash folder holds up to 512 packages for up to 48
hours. To disable the trash folder (for a given scope), use
raco pkg config --set max-trash-packages 0
(I expect that some variant of Greenspun's rule predicted the eventual
inclusion of "backup" management in the package system.)
