2

I have a bunch of software git-cloned into my site-lisp/ directory. It and all of its sub-directories are in my load-path. The problem I noticed is that package-install sometimes insists on pulling dependencies into elpa/ even when such packages already exist in site-lisp/. To be more specific:

package-install helm-descbinds insists on installing Helm 1.5 even though not only do I have the latest helm in in my load-path from site-lisp/helm/ but by the time the install gets called, (require 'helm-config) will have happened.

Who's at fault here? Is it the helm-descbinds package itself and I should be raising an issue with its maintainers? Or is there some obvious knob I need to turn in packages so the existing functionality gets picked up? Basically I just want to be sure that stuff in site-lisp/ gets precedence. This very well maybe the case already, but then why install stuff that's already available?

Gilles 'SO- stop being evil'
  • 21,702
  • 4
  • 53
  • 89
zeRusski
  • 335
  • 1
  • 8
  • What did you expect? You bypass package.el, and wonder that it doesn't magically know about what you installed manually? –  Dec 25 '14 at 14:03
  • I guess I expect it to at least check my `features` list and see **helm** already there? Maybe I'm overthinking it. – zeRusski Dec 25 '14 at 14:46
  • Packages are not the same as features. –  Dec 25 '14 at 14:51

1 Answers1

1

It's alright if package installs a different helm version. The important part is which version gets require'd first. So if you put your (require 'helm-config) earlier than package does, you're fine. Just to make sure that you have to correct one:

(add-to-list 'load-path "git-helm-path")
(require 'helm-config)

edit:

It seems from your comments is that your issue is with PATH priorities. load-path is just like PATH in Unix: the first file on the list that provides helm will be loaded when you require helm.

It's fine to have multiple versions of helm on the path, as long as you know what you're doing. If you want a relaxed approach, just delete your git stuff and leave everything to the package manager. Otherwise, you'll have to work for it and make sure that your load-path is properly set up. There's no magic pill, otherwise we'd have it in Unix.

abo-abo
  • 13,943
  • 1
  • 29
  • 43
  • I would've thought that all package-install does is download, then add directory to the **load-path**. Having to `(require 'helm-config)` before installing anything else seems really dissatisfying if only for the fact that Emacs doesn't make a good use of information that it already has. Having added everything in my **site-lisp/** to **load-path** I then bulk-install packages with package-install and then config them. Question is which features get picked up? `features` list shows helm and friends there, but which files are being used site-lisp or elpa? Am I not thinking straight? – zeRusski Dec 25 '14 at 14:44
  • @zeRusski You confuse features and packages. These are orthogonal concepts. Compare [Named Features](https://www.gnu.org/software/emacs/manual/html_node/elisp/Named-Features.html#Named-Features) and [Packages](https://www.gnu.org/software/emacs/manual/html_node/elisp/Packaging-Basics.html#Packaging-Basics). –  Dec 25 '14 at 14:56
  • @lunaryorn right, tu for pointers. `symbol-file` and `load-history` do confirm that the elpa version gets loaded. Oh, fancy `list-load-path-shadows` actually shows what's shadowed. – zeRusski Dec 25 '14 at 15:34
  • @zeRusski Add your site-lisp directory to `load-path` "after* calling `package-initialize`. That should make sure that your manually installed version gets loaded. But ideally, pick one way and only one way of installing stuff. Everything else is asking for trouble. –  Dec 25 '14 at 15:39
  • @abo-abo unless I'm very much mistaken your solution will only work if "git-helm-path" (that is my **site-lisp/** subdirs) appears earlier in **load-path** than packages in elpa? Which means I need to juggle the **load-path** before stuff gets required – zeRusski Dec 25 '14 at 15:47
  • You can either 1: load before package-init, 2: load after package-init, 3: add path after package-init and not load. The only bad option is to add path before package-init and not load. – abo-abo Dec 25 '14 at 15:51
  • @lunaryorn I think your suggestion is right on target. Thanks – zeRusski Dec 25 '14 at 15:52