Closed aspiers closed 8 years ago
Hmmm, actually it seems that :loader :built-in
works if the path is in load-path
. Can you confirm this is the right approach? If so, all we need to do is document that.
The idea for :built-in
loader was to let user choose between built-in elpa
and repo elpa
packages if some clashes are present. E.g. some time ago there are were two versions of flymake - built-in
and melpa
.
You probably should create your own loader for this case. And of course package should be on load path to load it. The same as when using use-package
. This is needed because in internals it just does require
and eval-after-load
stuff, so emacs should know where the package is.
Also keep in mind that if you use el-get more often than elpa you could tweak loaders priority map, so you wouldn't need to explicitly specify el-get anywhere.
Thanks. Given that :loader built-in works fine, what would the benefit of a custom function be?
Honestly I never used build-in
loader at all. But by the idea this loader is supposed to be used for different thing, so chances are to get something broken some day, when using build-in
loader for wrong purpose.
OK, I guess I'll use it and wait for it to break then - then I'll have the answer to my question ;-)
If I have an emacs package somewhere in my home directory (e.g. via
git clone
, if I'm maintaining or contributing to development of that package), how do I getreq-package
to load it?Clearly
:loader :elpa
or:built-in
are wrong. I could maybe use:el-get
, except that el-get sucks for this use case due to https://github.com/dimitri/el-get/issues/1171Ideally I could just specify a path which
req-package
would ensure is onload-path
(or maybe it would be better if I ensureload-path
contains that path myself, rather than expectingreq-package
to add it), and then it would simply load it from there, similarly to if it was loading a built-in.