Integration with use-package slows down its exploratory uses

[ubolonton]

When either straight-use-package-by-default is t, or :straight t is used, interactively evaluating a (use-package ...) form is slow (2-3 seconds), even after the package is already loaded. This makes it cumbersome to incrementally configure a package, when the form is repeatedly tweaked and re-evaluated.

I'm not sure if this is specific to my setup, or whether that's the behavior in general. I chased it down to this modification check in straight-use-package.

Maybe the :straight handler can somehow treat interactive evaluation differently?

[raxod502]

Yes, this is a problem in general. See this section for information on how to make modification checks faster, although this does not fix the underlying problem.

There are several ways to fix this (e.g. say that by default, packages will only be checked for modifications once per Emacs session). I'd be open to proposals.

[ubolonton]

My proposal would be skipping any checks if the package is already loaded.

[raxod502]

To avoid surprises, I would say that we should actually refuse to load the package at all if it's already been loaded—and then clearly document this.

We already do this within a single transaction. How about doing the same globally?

[ubolonton]

That wouldn't fix the slow interactive evaluations. I think such behavior would be ok (as the default) for the core, low-level interface straight-use-package, but not for use-package, which is more or less a glorified require.

How about making straight-use-package refuse, but having use-package-handler/:straight ignore by default? Something like this:

;;; The setting could use a better name, otherwise it can be misunderstood
;;; as altering the behavior of `straight-use-package`.
(if straight-use-package-ignore-already-loaded-error
    (condition-case nil
        (use-package ...)
      (straight-package-already-loaded-error nil))
  (use-package ...))

[raxod502]

That wouldn't fix the slow interactive evaluations.

I think it would. The reason the interactive evaluation is slow is that straight.el is checking packages for modifications so that it can tell if it needs to load them again. If it refused to re-load packages, then the check wouldn't happen.

To be clear, when I say "refuse", I mean silently return t—not throw an error.

[ubolonton]

To be clear, when I say "refuse", I mean silently return t—not throw an error.

Oh I misunderstood. I have no objection, then.