`el-get` recipes #29

priyadarshan opened this Issue Mar 2, 2014 · 15 comments


None yet
3 participants

Would it be possible at all to add el-get recipe syntax as one of the supported sources? https://github.com/dimitri/el-get/tree/master/recipes

Their usefulness lies in the ability to also handle external commands, in order to install complicated packages. See for example bbdb:

I cannot help with code, but I would be very happy to help with testing.


steckerhalter commented Mar 3, 2014

Looking at the bbdb el-get recipe:

(:name bbdb
       :website "http://bbdb.sourceforge.net/"
       :description "The Insidious Big Brother Database (BBDB) is a contact management utility."
       :type git
       :url "git://git.savannah.nongnu.org/bbdb.git"
       :load-path ("./lisp")
       ;; if using vm, add `--with-vm-dir=DIR' after ./configure
       :build `("./autogen.sh" "./configure" "make")
       :features bbdb-loaddefs
       :autoloads nil
       :info "doc"
       :post-init (bbdb-initialize))

and then at the MELPA recipe:

 :url "git://git.savannah.nongnu.org/bbdb.git"
 :fetcher git
 :files ("lisp/*.el*" "doc/*.texi"))

what exactly is really needed from the el-get recipe here? most of this is covered in quelpa by elpa conformance (metadata, features, autoload, docs etc.)

we debated adding support for something like :build but postponed that as it didn't seem necessary for packages to work

it would be probably possible to build a compatibility layer in front of quelpa that transforms el-get recipes into melpa recipes. internally we are using the library from melpa to build packages so everything else would have to be added by us and then we are not really compatible with melpa anymore.

another problem could then be that many repos that el-get has recipes for do probably not conform to the elpa standard (missing deps in the header etc.) so they would fail to build and install.

these are just some thoughts. maybe you'd like to add something?

To me as a user, it would be ideal to have quelpa the only tool I need to deal with all install cases.

The 'bbdb' recipe was of course just as an example. MELPA as an external build service builds things for the final user. In the future, as you said it would be useful to have something like :build, if one needs to create a quelpa recipe that needs local building, similar to the bbdb one.

It would be quite useful to be able to deal with non-elpa-conforming packages too, so one would be able to use perfectly working packages that still needs minor adjustments to adhere to the elpa standard. That happens, for example, where a package's developer is not avalable, or perhaps just not willing, to add the proper elpa machinery. Forking the code just for that requirement (as it was suggested on reddit/r/emacs a while back) does not sound like the best way to deal with such cases.


steckerhalter commented Mar 3, 2014

can you give any examples that cannot be used currently with quelpa? I think it would be easier to work with some examples and then see what we could do about it...

Sure. Let's say one need to use skk with Emacs (a Japanese input method). There is a package:
It is not on MELPA, the alternative would be of course to install it manually or to use el-get. In either case not ideal if one would like to use only one package manager, ie quelpa.

It would be nice if quelpa, perhaps in some future phase, could handle packages that are not in MELPA, nor will likely will be for a while.

If looking for more examples of packages not on MELPA: Sacha Chua's artbollocks-mode, https://github.com/sachac/artbollocks-mode

Sorry, wrong example. quelpa can already do that!


steckerhalter commented Mar 3, 2014

it would be nice if quelpa, perhaps in some future phase, could handle packages that are not in MELPA, nor will likely will be for a while.

it can handle packages that are not on MELPA, but only if these can be made to work with the melpa recipe format. like for example my package https://github.com/steckerhalter/discover-my-major using a command like:

(quelpa '(discover-my-major :fetcher github :repo "steckerhalter/discover-my-major"))

I had a look at the ddskk. it's really cryptic. the docs are in japanese, the installation procedure is really weird and it's hosted on cvs even with the need to login to access the source (which package-build does not support currently).

@steckerhalter steckerhalter reopened this Mar 3, 2014


steckerhalter commented Mar 3, 2014

oops, wrong button. so are you using that ddskk?

we might add some features. for example to be able to use a single .el or .el.gz but in general that should not be expanded too much. after all quelpa is supposed to be simple. I think you can already install everything that any of the package archives (melpa, marmalade, gnu elpa, org elpa) has in some form.

today it's a bit like:

if your package is not on one of the archives it's probably irrelevant or seriously outdated

a good example is ddskk. to add support for that we would need to do a lot of nasty things. el-get does these things. it even can install OS packages and probably fly to the moon.

so instead of making quelpa conform to every fossil out there it would be better to take the fossil and update it so that quelpa can use it, meaning that someone who cares about the fossil forks it and maintains it.

I can help you with that if you want to use such a fossil.

Yes, ddssk is quite an extreme case. I am using el-get for that one. https://github.com/dimitri/el-get/blob/master/recipes/ddskk.rcp

quelpa is already quite better than just relying on MELPA! I shall be very happy to use it, and use el-get for edge case scenarios.


steckerhalter commented Mar 3, 2014

hmm, is this skk a unique way to write in japanese? do japanese prefer to use that or are there other systems? how did you came to use the package? (I'm kind of interested because I thought about learning the japanese characters)

ps: so I found that Emacs provides support for japanese input M-x set-input-method japanese RET. what's the difference to this ddssk?

skk assumes QWERTY keyboards and converts Japanese Roman to Japanese Kana. One of the differences with built-in Emacs support is that skk converts words one by one (single-word conversion), without analysing syntax or grammar. Instead, users specify the border between Kanjis and Kanas. This means you can write dialects, written or spoken words, ancient words as well as standard words in the same manner.

PS: I am not sure what regular Emacs Japanese users prefer to use. Good luck with your learning Japanase. It is a beautiful language.


steckerhalter commented Mar 4, 2014

thanks. I was thinking about this issue with packages like ddskk. one way to handle this that is not so awful would probably be preprocessing. so one would write a normal melpa recipe. we add a feature where you can pass some elisp code that preprocesses the checked out source code. so in the case of ddskk that would prepare the code so that package-build can build and install it.

if you know similar packages please add them here...

That would be wonderful!

Perhaps one possible way to find more packages similar to ddsk, could be to sort the el-get packages recipes not found in MELPA, and look inside those for some meaningful keywords?

Thank you once again for quelpa.


steckerhalter commented Mar 6, 2014

good idea. we should be able to find some packages that serve as a test bed like that.

Thank you once again for quelpa.

you're welcome. thanks for helping with your valuable input.


wasamasa commented Mar 11, 2014

Closed, further el-get discussion goes on here: #35.

@wasamasa wasamasa closed this Mar 11, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment