Emacs package development with spacemacs

[gdkrmr]

What is the best work flow to develop an emacs package with spacemacs that is part of a layer and where the installation is handled by spacemacs?

[robbyoconnor]

What do you mean?

[robbyoconnor]

This is how you do a new layer: #4958

[robbyoconnor]

http://develop.spacemacs.org/doc/LAYERS.html

[Compro-Prasad]

@gdkrmr Making an Emacs package means solving your own problem. If it is a general problem for others too then you can for sure distribute it on MELPA(its very easy to add there). Then you can create your own layer and include your own package or extend an existing layer in Spacemacs. Finally, make a PR to include the package in Spacemacs.

[gdkrmr]

I am not talking about a spacemacs layer, I am talking about the work flow of developing an emacs package using spacemacs. Especially if the package itself it is already installed by a layer.

[Compro-Prasad]

It is a bit of setup. You will have to clone the actual package, put it in a separate location, remove the package from spacemacs and update the load-path. This is easier if we use straight.el but spacemacs currently doesn't support it. We will need to wait for another year to see what happens with straight.el.

[gdkrmr]

ok, thanks. There is the dotspacemacs-excluded-packages variable, can I just add my package here, clone it somewhere and add the location to the load-path?

[Compro-Prasad]

Yup. That is what I know of. If others have some different ways of doing it then they might hop in to help.

[robbyoconnor]

You can publish it - or can you use quelpa, there are examples all throughout spacemacs on how to use it quelpa in layers. You SHOULD publish to melpa if you want exposure.

[gdkrmr]

@robbyoconnor if the package is already published on melpa, how would I make spacemacs prefer the local/quelpa/forked version?

[bmag]

@gdkrmr I think the best option for developing a package is using it as a local package. It'd be easier to help if you can tell us what package you are developing.

Pros:

• no need to commit changes for Spacemacs to pick them up (with quelpa you need to commit and update the package via regular update packages mechanism)
• faster to test changes because you don't need to reinstall the package every time you make a change

Cons:

• Spacemacs doesn't handle package dependencies automatically for local packages IIRC
• if the package has a complicated installation process or a complicated file structure, things get more complicated (with quelpa it shouldn't matter, as long as you use the correct recipe)
• [EDIT] no auto-generation of autoload files

To develop the package as a local package, you can create a private layer and add the package you are developing as a local package. If it has dependencies on other packages, you need to add them to the new layer's list of packages (and also add init functions), since Spacemacs doesn't detect dependencies for local packages IIRC. If the dependencies are also part of Spacemacs, you could rely on the official configuration instead of adding them to the new layer.

If the package you are developing is part of Spacemacs, you will want to copy its init function to the new layer. That will make the new layer own the package instead of the original official layer, and override the original init function IIRC.

When testing your changes, you need to be aware if Spacemacs alters the package behavior in some way - that really depends on the package. If the package has automatic tests (e.g. make test) it is much easier.

EDIT: local packages don't auto-generate autoload files, see below for how to overcome.

[gdkrmr]

I am using the julia layer #10444, I simply copied the files to my private layer directory and disabled ess manually, everyting works fine without the changes below.

I have played around with this a little bit and was not really successful, I tried the following:

1. The .spacemacs comment for dotspacemacs-additional-packages tells to add this:

(dotspacemacs/layer
  ...
  dotspacemacs-additional-packages '((julia-repl :location "~/progs/julia/julia-repl/"))
  ...)

which does not work: (void-function julia-repl-mode)

2. changing the package.el of the julia layer:

(defconst julia-packages
  '(...
    (julia-repl :location "~/julia/julia-repl/")
    ...))

does not work either: (void-function julia-repl-mode)

3. The closest I have come is:

(dotspacemacs/layers
  ...
  excluded-packages '(julia-repl)
  ...)
(defun dotspacemacs/user-init
  (add-to-list 'load-path "~/progs/julia/julia-repl/")
  (require julia-repl))

which works, but the key bindings are not loaded from the julia layer.

[gdkrmr]

The spacemacs documentation tell you to put local packages in /layer/local/package/, I tried that and changed

(defconst julia-packages
  '(
    ...
    (julia-repl :location local)
    ...))

without success: (void-function julia-repl-mode)

[bmag]

Right, I forgot to add that local packages don't generate autoload files, so anything that is autoloaded will cause void-function or void-variable errors. The hard way to handle it is via the :commands parameter of use-package declarations. Another way is to manually generate autoload files (Emacs has built-in commands for that) and load them via load function in init, pre-init or config.el. Can't give you a detailed guide on this right now, but I think it's doable.