4

TL;DR: Is there a way to have straight.el not check out a package via git repo, and have it download slim melpa packages like package.el does? Also, is there a way to have it refrain from automatically downloading a lesser-used package until I manually tell it to?

I'm trying to switch to straight.el from package.el because reproducible configs and seamless integration of non-MELPA packages sound very attractive. I've added the bootstrap code to init.el, added (straight-use-package 'use-package), and put :straight t on all use-packages. Unfortunately, this makes straight.el pull eeeeeverything from git repos. This creates two problems:

  1. My ~/.emacs.d has inflated from 82MB to 2.4GB and counting. I cannot afford this much storage on one of my laptops, especially considering that 99% of that storage is wasted: I'm never going to hack on most of those packages!
  2. The initial checkout takes forever. When I said "and counting", I meant it's been taking about 30 minutes just to check out a single package, and there are a dozen more. It's currently stuck on mozc, which is a 78KB single-file elisp program living in a gargantuan C++ project. straight.el is trying to pull the whole 1GB+ repo so I can get access to a long history of C++ files that won't even get compiled.

So I would like to have straight.el just download MELPA packages for things that are on MELPA and that I don't intend on modifying. But writing e.g. (straight-use-package '(mozc :source (melpa gnu-elpa-mirror)) doesn't help; straight.el still pulls the repo. Seeing the official docs' notes on backends, I'm guessing that getting packages from anywhere besides git is an unimplemented feature, but is this right?

As an additional, related goal, I'd like straight.el to refrain from automatically downloading every single package on startup. For instance, I don't want lsp-mode installed until and unless I open a file whose major mode is set up to use lsp-mode. But I can't seem to find any info on this. Is there a way to configure packages without downloading them until there's demand?

Jun Inoue
  • 195
  • 6
  • It sounds like `straight.el` is doing exactly what it was intended to do, and your use case is not compatible with its current feature set. I think your options are to use `package.el` with MELPA stable, or (which is what I do), use `package.el` and MELPA for things where you just want the 'slim' version, and install direct from Github for the things you want more control over (with or without `straight.el`). – Tyler Apr 08 '22 at 15:44
  • @Tyler Yeah, I was starting to suspect that... That's unfortunate. Thanks for the tip, but I think this is a dealbreaker for me. – Jun Inoue Apr 09 '22 at 04:11
  • @Jun Inoue, you are not on the right way - the ```mozc``` package (git) must be cloned on your computer and the executables must be built/installed according to the procedure suitable for your OS - see the installation documentation. The file ```mozc.el``` is the interface between Emacs and ```mozc``` application (which will be the server in this case) and it is not part of building/installing. Later must be added directly in your ```init.el``` without ```straight``` - simply add ``` (load-file "/path/to/mozc.el") (setq default-input-method "japanese-mozc")```. – Ian Apr 09 '22 at 06:07
  • Later I can post an answer to the reducing ```straight``` bloating. – Ian Apr 09 '22 at 06:09
  • @Ian That's the thing, MELPA takes care of all that--isolating `mozc.el`, cutting down space, and making sure it appears on the path--, and AFAICT introducing `straight.el` takes away those benefits. And for what? I don't need or want developer access to `mozc.el`. The insistence of `straight.el` on checking out git repos for everything just doesn't make sense, because no one is a contributor to every single package they use. I think it can really use an option to coexist with "use-only" packages, which is what I was hoping to learn how to do. – Jun Inoue Apr 10 '22 at 13:07

2 Answers2

3

You must first clone and then build/install the mozc application. The mozc.el file is the interface between Emacs and your mozc application. Read the comments at the beginning of the file how to be added later.

  1. To reduce the size of a git cloned package, use the command:
git clone --depth 1 your-git-source-package your-destination-folder

The switch --depth will help downloading a single commit, not the whole history.

  1. The straight package uses the variable straight-vc-git-default-clone-depth by default initialized to 'full, downloading the whole history. This may be customized in your init.el file, to the value 1 or even better '(1 single-branch). See the code snippet below.
;; keep this line here to shorten emacs-init-time
(setq straight-check-for-modifications '(check-on-save find-when-checking))

(defvar bootstrap-version)
(let ((bootstrap-file
       (expand-file-name "straight/repos/straight.el/bootstrap.el" user-emacs-directory))
      (bootstrap-version 5))
  (unless (file-exists-p bootstrap-file)
    (with-current-buffer
        (url-retrieve-synchronously
         "https://raw.githubusercontent.com/raxod502/straight.el/develop/install.el"
         'silent 'inhibit-cookies)
      (goto-char (point-max))
      (eval-print-last-sexp)))
  (load bootstrap-file nil 'nomessage))

(straight-use-package 'use-package)
(setq straight-use-package-by-default t)
(setq straight-vc-git-default-clone-depth '(1 single-branch))  ;; instead of the default 'full
(setq use-package-verbose nil) ;; use 't' to see execution profile at startup

My use case: for ~190 packages, the size of straight folder was reduced from 900MB to 315MB with the above settings. If such amount is still unaceptable for you, then MELPA packages...

  1. As for your last goal - emacs downloads from internet all listed packages in your init.el file. At startup not all packages may be loaded into operating memory, some of them can be lazy-loaded - see the documentation for use-package. u
Ian
  • 1,321
  • 10
  • 12
  • This does mitigate the problem as stated. It's still too wasteful for my taste, but the fact that this comes up as an answer helps me to gauge what `straight.el` is or isn't meant to do. So thank you. – Jun Inoue Apr 10 '22 at 13:09
0

From Emacs 29 onward, you might be interested in using package-vc. This is a new feature that optionally extends package.el by providing an alternative way to fetch package sources.

The default remains to download tarballs from an ELPA server, but now you can use commands like M-x package-vc-install to clone a repository for a package directly. package-vc can infer the right repositories for a number of packages, so you can do something like M-x package-vc-install denote RET without the need to look up where the package is developed. If the package you want is not part of any package archive, you can also pass package-vc-install a URL or use the user option package-vc-selected-packages. To quote an example from the manual ((emacs) Fetching Package Sources):

An alternative way to use package-vc-install' is via the package-vc-selected-packages' user option. This is an alist of packages to install, where each key is a package name and the value is nil', indicating that any revision is to install, a string, indicating a specific revision or a package specification plist. The side effect of setting the user option is to install the package, but the process can also be manually triggered using the function package-vc-install-selected-packages'. Here is an example of how the user option:

 (setopt package-vc-selected-packages
         '((modus-themes . "0f39eb3fd9") ;specific revision
           (auctex . nil)                ;any revision
           (foo                          ;a package specification
            :url "https://git.sv.gnu.org/r/foo-mode.git"
            :branch "trunk")))

The properties used in a package specification are explained in the `package-vc-install-selected-packages' documentation string.

Mixing VC packages and regular packages is no issue at all. You can download a VC package on top of an already installed package, just for a short time to change a few things and send the changes to a maintainer (package-vc-prepare-patch) or create a bug report (package-report-bug), and then revert back to a regular package afterwards using a regular M-x package-delete.

Philip K.
  • 136
  • 2
  • Sounds very promising! I'm still stuck with Emacs 28 and 27 for various reasons, but I'll definitely give this a try once I get to upgrade. – Jun Inoue Jan 16 '23 at 05:40