7

When I'm writing a new package, it's great that I can test its installation by just issuing M-x package-install-from-buffer. This will install the package with package.el, so that it goes under "~/.emacs.d/elpa". However, this doesn't work on multifile packages.

What is the procedure for installing all .el files in the current directory as a single multifile package?

6

Emacs 25.1 now has this feature. From the NEWS file:

** package-install-from-buffer and package-install-file work on directories. This follows the same rules as installing from a .tar file, except the -pkg.el file is optional.

There are no new commands to remember. Just issue package-install-from-buffer from a dired buffer, or invoke package-install-file and give a directory. Whichever package is contained in that directory will be read and installed, be it single or multifile, no taring or -pkg.el file necessary.

  • Optional -pkg.el file is interesting. What do the values default to in that case? – phils Jan 21 '15 at 2:19
  • @phils just like the package repositories do, it finds an elisp file with a complete package header and generates the -pkg file from that. – Malabarba Jan 21 '15 at 2:22
  • 1
    Ah, I hadn't realised that's how they were generated normally. Your changes make perfect sense, then. Nice work. – phils Jan 21 '15 at 2:29
  • Malabarba: I notice that the current docstring in trunk for package-install-file makes no mention of it working for directories (although, as you've said, it does). – phils Jul 15 '15 at 12:14
  • @phils Thanks for noticing. I'm fixing it now. – Malabarba Jul 17 '15 at 18:08
1

package-install-from-buffer says:

The current buffer is assumed to be a single .el or .tar file that follows the packaging guidelines

So one presumes you can archive the directory (assuming it meets the criteria), load the tar file into Emacs, and use package-install-from-buffer as before?

Edit: Or, as lunaryorn points out, don't visit the archive in Emacs, and use package-install-file.

  • 1
    Sounds like a function to (re-)tar the current dir and then do the package install would be handy. – glucas Jan 12 '15 at 0:59
  • 1
    Alternatively, M-x package-install-file. – lunaryorn Jan 12 '15 at 11:03
  • Doesn't work. It tries to find a paradox/paradox-pkg.el file inside the tar, and errors when it doesn't. Same for both install-file and install-from-buffer. I'm guessing I need to create this -pkg file as a recipe of sorts. – Malabarba Jan 12 '15 at 11:38
  • 1
    @Malabarba A TAR package must have a -pkg file, otherwise it's not a valid package, so just tar'ing a random directory won't work. Emacs must have some place to look for the package metadata after all. You can use MELPAs package-build or cask to create proper TAR packages from a directory tree. – lunaryorn Jan 12 '15 at 12:09
  • Malabarba: See C-h i g (elisp) Multi-file Packages for details. – phils Jan 12 '15 at 20:30
1

package.el does not have good support for this use case. You have to re-run package-install-from-buffer every time you make an update to the package, and also M-x find-function and friends will not jump to the source code, but rather the copy that package.el puts in ~/.emacs.d/elpa. As a consequence, I would recommend not using package.el for this use case (or at all, since it has a number of other problems).

Instead, you can try my package manager straight.el, which is explicitly designed for this use case. With straight.el, there is no "local installation" procedure. You just put your repository in ~/.emacs.d/straight/repos/<my-package-repo>, and then load the package in your init-file:

(straight-use-package '(<my-package> :local-repo "<my-package-repo>"))

Anytime you make a change to the source code, autoload generation and byte-compilation is redone (once you restart Emacs). Also, you're running directly from the Git repository, so M-x find-function and friends will work as expected.

Finally, local and upstream versions are entirely interchangeable. straight.el lets you make any local changes you want, and they are treated as just as sacred as upstream changes (although straight.el does let you automatically [and interactively] revert your repositories to their upstream versions, if you wish). Thus, there is no concern with making any changes to your configuration if you want to do local development: just do local development. And if you have a private package that you publish, it's trivial: just push that package somewhere (and probably update the recipe in your init-file to point to that Git repository, so that straight.el can re-clone it from a different machine).

Unlike with package.el, there is no difference in the treatment of multi-file and single-file packages.

For verbose documentation about straight.el, including comparisons to other package managers, see the README.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.