Closed senny closed 9 years ago
The bundles I would like to move to emacs-contrib
are:
@jone, @tonini what do you think?
I really find that is a good idea.
I see the bundle list for cabbage-contrib
as you listed above:
In general I think it's a good idea :)
bundles
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?
@senny whats the status about this issue? I guess it's done right?
Status: :green_heart:
It's a heart-warming morning ;-)
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.