cabbage bundle repository to keep the core small
senny opened this issue · 11 comments
I think it's crucial to keep the core of cabbage small and focused. Otherwise we will soon face bundle overload and cabbage will take a long time to install. This hurts the "getting started quickly" experience and surly is not the best thing for newcomers.
Also I would like to have the core of cabbage be as good supported as possible. With bundles around, that are just used by a few people this is very hard to achieve. In my opinion the core of cabbage should be the bread and butter that you need to work in any given language we support.
On the other hand I like that users can contribute bundles. This helps you get started with a particular emacs package and have it already preconfigured.
To solve this conflict I suggest we everything outside the scope of the core in a repository called cabbage-contrib
This is an archive of many different bundles that we can accumulate over time. The quality of these packages are not directly assured by us so it could be that some of them are broken and don't work anymore.
This relates to #150. If we got that functionality working we can just append the cabbage-contrib dirs to the bundle and vendor path and everything should work as expected.
It would be good to generate a list of bundles that we want to move from the cabbage repository to the cabbage-contrib repository.
The bundles I would like to move to emacs-contrib are:
- irc
- jabber
- cabbage-developer (I think we can talk about that one)
- terminal
- maximize (I'm not sure about that one)
- rect-mark (If this one is used broadly I suggest we embed it into the power-edit bundle)
- company (I think this one should be part of the completion bundle, If we decide to only support auto-complete in the core we should move it to contrib)
I really find that is a good idea.
I see the bundle list for cabbage-contribas you listed above:
- cabbage-developer I'm also not sure about that one, in my opinion this one should be in core.
- it isn't a bad idea to put rect-mark into power-edit, I would vote for that one.
In general I think it's a good idea :)
bundles
- Terminal -> maybe I wouldn't move this one but just delete it, depending on how fast we are doing the change (it is deprecated and I didn't hear of anyone using it)
- maximize -> maybe this should be a configuration option, not a bundle? I think it is still used on osx installations without the fullscreen patch (btw. does the newest emacs include native fullscreen for osx?)
- rect-mark -> I'm fine with merging it into power edit
- cabbage-developer -> since the binding was moved to ergonomic: could we get rid of this one and enable the binding by default? It has only this persp binding :/
installation
How does this influence the installation and update scripts?
Is contrib automatically installed by default?
dependencies (assuming we install contrib automatically)
I think this does not directly solve the problem that we have lots of submodules - the submodules are only moved.
Maybe it's a good time now to think about how we could improve the handling of vendor dependencies?
@jone no it does not solve the dependency problem but I think this is a problem we are not going to solve anyways (except we keep the dependencies low, and this is exactly the situation you'll get when you use core only). I would not install contrib by default beacuse the core should have everything you need to get started. As you get better with Emacs you will be looking for more options and thats when contrib comes in. Also I want to make a distinction between bundles that, we make strong effort to get them working properly on every platform and distribution and the ones that are just created and shared. I think the bundles in core should be solid, work on windows, linux and mac, and on the different Emacs distributions (Aquamacs, Emacs perhaps even XEmacs).
So I think cabbage contrib should be a separate repository we host to share bundles we use and someone might use.
Ok, then.
How should it plug in easily? Can I just check it out somewhere, maybe run a script? Or do I have to register the paths in init.el?
Maybe we could expect it to be in a git-ignored sub directory in the core checkout, so that we could guess the paths :/
How is it updated? Does it provide a seperate update script? Should the core update script also update contrib?
I think an upgrade script is necessary because of the submodules..
When #150 is ready we can configure a relative path to the cabbage directory where the contrib repository lives. Cabbage will then pick up that directory whenever it's present.
I think we need an update script. If we integrate contrib into the main repository we could use our primary update script to also update contrib.
We now have the possibility to configure additional bundle paths. What do you think about making the integration with cabbage-contrib simple?
Status: 💚
It's a heart-warming morning ;-)