Poor experience with (use-package :ensure t ... :straight ...)

[ieure]

I moved my Emacs config over to use-package earlier this year to improve startup times, and am trying out straight.el this week to better keep things in sync across machines.

I have a few packages I've written that I haven't gotten around to submitting to MELPA, and these are presenting problems for me. My assumption was that if I provided a recipe, straight.el would use it to install the package, and that would be that. However, there's a bad interaction with use-package.

Here's an example:

(use-package nssh
  :defer t
  :ensure t
  :straight (nssh :host github
                  :repo "ieure/nssh-el"
                  :tag "v0.9.10"))

When I eval this, my package archives are refreshed:

Importing package-keyring.gpg...done
Contacting host: stable.melpa.org:80 [2 times]
Contacting host: elpa.gnu.org:443
Package refresh done

And then I get this warning:

Error (use-package): Failed to install nssh: Package ‘nssh-’ is unavailable

Despite all that, my package is installed and works fine:

phaktory!ieure:~$ ls -ld ~/.emacs.d/straight/repos/nssh-el
drwxr-xr-x 1 ieure ieure 40 Oct 24 13:39 /home/ieure/.emacs.d/straight/repos/nssh-el/

However, this unacceptably delays Emacs initialization, as it refreshes packages multiple times (once per recipe which doesn't exist in package-archives) and spams the fresh Emacs with *Warnings*.

A similar experience can be had if you use-package anything which isn't available in package-archives, for example if you remove GNU ELPA and try to install exwm.

The issue appears to be that :ensure t causes use-package to install via package.el, even though :straight ... causes installation via the provided recipe.

It would be ideal if :ensure t was ignored when :straight was provided, but failing that, a warning or item in the documentation would be welcome.

[vyp]

I think it might be use-package handling the :ensure t, not straight.el.

[ieure]

I think it might be use-package handling the :ensure t, not straight.el.

It is.

[vyp]

So I'm not sure if straight.el can do anything about this. I think you just have to comment out any :ensure t anytime you add a :straight form, and uncomment it if you want to switch back. Readme already has this which mentions removing any :ensure t:

You should remove any code that relates to package.el; for example, references to package-initialize, package-archives, and (if you're using use-package) :ensure or use-package-always-ensure. While it is technically possible to use both package.el and straight.el at the same time, there is no real reason to, and it might result in oddities like packages getting loaded more than once.

Isn't that already suggesting incompatibility between :ensure t and :straight? Or how do you think it could be made clearer?

[raxod502]

The issue appears to be that :ensure t causes use-package to install via package.el, even though :straight ... causes installation via the provided recipe.

Yes. If you provide :straight, you are explicitly requesting the package to be installed via straight.el. If you provide :ensure, you are explicitly requesting the package to be installed via package.el. If you provide both, well, you get what you asked for. That's why the documentation for straight.el suggests to remove all traces of :ensure from your init-file.

I will also point out that straight.el doesn't really have anything to do with your original problem. If you removed :straight from (use-package nssh :ensure t ...) then you'd get exactly the same startup delay and warnings.

It would be ideal if :ensure t was ignored when :straight was provided, but failing that, a warning or item in the documentation would be welcome.

As per your suggestion, I made it so that :ensure is ignored when :straight is provided. Let me know what you think.

[progfolio]

Let me know what you think.

Looks like it's working fine to me!