straight-check-package causes subsequent calls to straight-freeze-versions to omit dependencies

[mjoerg]

What's wrong

When calling straight-check-package a subsequent call to straight-freeze-versions will prompt to reload the init file and if confirmed will result in package dependencies missing from the generated lockfile.

Directions to reproduce

1. Run bug.sh
2. M-x create-bug-report
3. y for prompt "Caches are outdated, reload init-file? (y or n)"

This demonstrates the issue by setting up package f.el and then calls straight-check-package and straight-freeze-versions. The generated lockfile misses dash.el and s.el.

Output from my setup

• bootstrap straight.el

  Bootstrapping straight.el...done
  Rebuilding all packages due to build cache schema change
  Looking for gnu-elpa-mirror recipe → Cloning melpa...done
  Looking for emacsmirror-mirror recipe → Cloning gnu-elpa-mirror...done
  Looking for emacsmirror-mirror recipe → Cloning el-get...done
  Looking for straight recipe → Cloning emacsmirror-mirror...done
  Building straight...done
  Cloning f.el...done
  Building f...
  Building f → Cloning s.el...done
  Building f → Building s...done
  Building f → Cloning dash.el...done
  Building f → Building dash...done
  Building f...done
  For information about GNU Emacs and the GNU system, type C-h C-a.

• Test run at: 2021-01-16 01:52:42
• system-type: gnu/linux
• straight-version: prerelease (HEAD -> develop, origin/develop) 8ba8ea9 2021-01-14
• emacs-version: GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22, cairo version 1.17.3) of 2020-08-28
• create lockfile:

  Processing repository "dash.el"...done
  Processing repository "s.el"...done
  Processing repository "f.el"...done
  Processing repository "straight.el"...done
  Processing repository "emacsmirror-mirror"...done
  Processing repository "el-get"...done
  Processing repository "gnu-elpa-mirror"...done
  Processing repository "melpa"...done
  Wrote /tmp/tmp.pxnZGNqlTT/.emacs.d/straight/versions/default.el

• lockfile (correct):

  (("dash.el" . "3726eb17f36ab740d4392cce435fa888982fea77")
  ("el-get" . "215ff5e56cedcc18866aba6e451b61c06a050e74")
  ("emacsmirror-mirror" . "faaf1ba1cba6ac726da4645f02967cf7ffa4b4f9")
  ("f.el" . "c4dbf8c8e83df834f5d6f72cd5649b9d8a8812ec")
  ("gnu-elpa-mirror" . "54a24bf1eca35819afa4e9f1676f8a028fe35ac6")
  ("melpa" . "fe3f9f732a69483bfa86446cd90f0f1c2611cc80")
  ("s.el" . "43ba8b563bee3426cead0e6d4ddc09398e1a349d")
  ("straight.el" . "8ba8ea9d7772c8ecfdfb5b3e35907c29e49402ac"))
  :beta

• check package
• recreate lockfile:

  Caches are outdated, reload init-file? (y or n) y
  Reloading "/tmp/tmp.pxnZGNqlTT/.emacs.d/init.el"...done
  Processing repository "f.el"...done
  Processing repository "straight.el"...done
  Processing repository "emacsmirror-mirror"...done
  Processing repository "el-get"...done
  Processing repository "gnu-elpa-mirror"...done
  Processing repository "melpa"...done
  Wrote /tmp/tmp.pxnZGNqlTT/.emacs.d/straight/versions/default.el

• lockfile (missing dependencies of f.el):

  (("el-get" . "215ff5e56cedcc18866aba6e451b61c06a050e74")
  ("emacsmirror-mirror" . "faaf1ba1cba6ac726da4645f02967cf7ffa4b4f9")
  ("f.el" . "c4dbf8c8e83df834f5d6f72cd5649b9d8a8812ec")
  ("gnu-elpa-mirror" . "54a24bf1eca35819afa4e9f1676f8a028fe35ac6")
  ("melpa" . "fe3f9f732a69483bfa86446cd90f0f1c2611cc80")
  ("straight.el" . "8ba8ea9d7772c8ecfdfb5b3e35907c29e49402ac"))
  :beta

Version information

• Emacs version: 27.1
• Operating system: Linux 5.10.6-arch1-1

[raxod502]

OK, looks like we've got one bug and one UX issue here:

• straight-check-package invalidates the recipe cache, which then leads to you being prompted to reload the init-file (UX issue, since this should be nondestructive but is nonetheless annoying)
• reloading the init-file in this situation should compute the lockfile correctly, but somehow it misses the dependencies (bug)

Thank you for the detailed report!

[raxod502]

Oh, and a quick note since it probably isn't obvious to anyone who didn't write the code---but the reason straight-check-package invalidates the recipe cache is because it operates by calling straight-use-package, which (in the general case) could add a new package, or reconfigure an existing one. I guess we could update straight-check-package so it calls directly through to the modification detection and build system layer, rather than going all the way from the top.