proposal - external layer support

[myrgy]

Hello @syl20bnr,

currently it's possible to to specify package location.
I think it would be awesome to have same possibility for layers. It should make spacemacs more agile, since some users will have ability to develop there own layers and share it among other users in a convenient way. Spacemacs will behave a core.

https://github.com/syl20bnr/spacemacs/blob/develop/doc/LAYERS.org#packagesel

Thanks!

[ezchi]

Is this what you want?

;; If non-nil layers with lazy install support are lazy installed.
;; List of additional paths where to look for configuration layers.
;; Paths must have a trailing slash (i.e. `~/.mycontribs/')
dotspacemacs-configuration-layer-path '()

[myrgy]

Not exacly, my idea is to provide github locations and allow spacemacs do pull it.

;; A package recipe 
(some-package :location (recipe :fetcher github :repo "some/repo"))

[gdkrmr]

great Idea, I would really love that! I had the same idea and to avoid clutter closed #10518, here is my reasoning why modular layers would be a great idea:

Seeing that there are not enough maintainers to merge all the pull requests, I would like to make a proposal to make spacemacs more modular. Right now this is nothing more than an idea in my head.

What about a modular layer system, just like packages. Instead of

rust

I would could do something like

(rust :fetcher 'github :repository "owner/rust-spacemacs-layer")

and it would pull that layer from github and install it somewhere (e.g. "~/.emacs.d/private/").

This way layers can be maintained separately from core spacemacs and more people can participate in development.

[syl20bnr]

I'm opposed to it in this exact form, instead I would like to provide support for installing layers from PRs.

Why ?

One of the raison d'être of Spacemacs is to break the package ecosystem scheme in order to provide both consistency and curation, i.e. good packages that behave similarly.

With an ever growing package ecosystem it becomes longer and harder to configure Emacs because there are a lot of options and all packages have their own ergonomics.

If I open the door to external layers then we will just replicate the same ecosystem just with one level of abstraction higher.

At some point we have to break this ecosystem to be able to design a beautiful system that can serve people directly.

While Spacemacs won't support officially these external layers, it is still possible to use them easily: this is to clone the git repository in your private layer directory.

But there is one kind of hybrid layers that are both external and official: the Pull Request layers. It would be awesome to provide facilities in Spacemacs to install them, test them, why not propose PR for this PR etc...

[gdkrmr]

That makes sense, it is quite simple to test a single PR by checking out the corresponding branch/repo, how would that work for more than one? There should maybe also be some facility to signal that one tested a certain PR and that it works, this way the maintainers would could set priorities on PRs.

[myrgy]

hence closed. Thanks!

[gdkrmr]

so, if I am on the develop branch plus some changes I made and want to try out the changes someone else made, is there a way to do this without doing all the merging myself?

[fiveNinePlusR]

you can clone a repo, copy the folder for the layer to ~/.spacemacs.d/layers/ if you are using the .spacemacs.d method. otherwise you'd need to add the folder under your ~/.emacs.d/private/layers/ folder. both ways you need to add the layer to the .spacemacs file or the init.el file depending on your config.

[gdkrmr]

I wanted to try the julia layer (#10444), but this layer modifies other stuff outside the layers directory, I have some personal changes to the ess layer therefore simply cloning the branch is complicated for me, but I guess that there is no way around it.

[myrgy]

You can branch from develop, comit your changes and merge checkout pr and merge it...