2

Is it possible to identify the package version of a local copy/clone/fork of a Elpa supported existing package?

Problem Scenario:

  • A Elpa supported package (lets called it package-foo) hosted on some Elpa compliant sites like GNU Elpa or MELPA has some problems. There might be several Pull Requests waiting for incorporation that have been sitting there for some time.
  • Let's say I clone the Git repo of that package and do the merge of the waiting fixes, potentially with some of my own fixes, pushing this all back to my hosted repo and potentially providing that as another PR on the original package-foo repo.
  • I install this clone of package-foo in a directory I put in my load-path.

All is fine and dandy I can use the package-foo without any problem. It does not have a package version though.

  • Now, if another package, lets say package-bar requires version X.Y of package-foo I run into a problem as Emacs will complain not being able to find it.

Is there a way I can identify a version to my copy of the package-foo?

What does not work:

  • I tried creating a package-foo-pkg file that I placed inside my extra directory that is in load-path (~/.emacs.d/utils), but it is not recognized (perhaps it is placed in the load-path too late?).

Work-around that works

  • I install the original package-foo inside the ~/.emacs.d/elpa directory so it can be recognized by Emacs.
  • The modified package-foo is inside ~/.emacs.d/utils.
  • load-path has ~/.emacs.d/utils before ~/.emacs.d/elpa, so Emacs loads the modified package-foo but is able to see the package version that is specified in the file stored inside ~/.emacs/elpa.

The disadvantage of this work-around is duplication plus the extra directory in ~/.emacs.d/elpa causing a little extra processing on Emacs startup.

The real solution to my problem would be the integration of the provided pull-request into the parent package. But I have no control over this.

Question: Is there a way I can use to assign a package version to my copy of package-foo that is located inside my secondary directory ~/.emacs.d/utils/?

14
  • Do the commands M-x package-install-file and M-x package-install-from-buffer solve your issue? – phils Jun 10 at 23:24
  • It's a work-around only. I store package-foo.el and I create a package-foo-pkg.el file that identifies the version x.y, inside a utils directory. Then calling (package-install-file "utils/package-foo.el") creates a elpa/package-foo-x.y directory with package-foo.el, package-foo-pkg.el and package-foo-autoloads.el. I don't need to put utils in my load-path. But if the package-foo has several files, I can't find a way to get them all in the created elpa/package-foo.x.y. Is there a way to handle this without having to create a elpa/package-foo.x.y directory? – PRouleau Jun 11 at 2:10
  • Besides, another reason I'm trying to not create the extra elpa/package-foo.x.y directory is the time consumed by the package mechanism to process all dependencies and loading when Emacs starts. As the number of package grows this seems to consume a large percentage of the Emacs startup time. Startup time does not increase when several Emacs Lisp files are stored inside one directory that is inside the load path. Then one directory can be processed for several files, not one directory per package as its the case for elpa based it seems. – PRouleau Jun 11 at 2:15
  • An extra test I did: I removed the package-foo.el and package-foo.elc from the elpa/package-foo.x.y directory only leaving the package-foo-pkg.el and package-foo-autoloads.el files inside that directory. The real package-foo.el is inside a separate directory, my utils directory. That also works. Emacs starts and does not complain about version x.y of package-foo missing. So it looks like creating the directory with the -pkg.el and the -autoloads.el is good enough. Emacs still has to process that extra directory that is put in my load-path though. I'd like to eliminate that. – PRouleau Jun 11 at 2:27
  • In the end, I'd still like to find a way to inform Emacs that my utils/package-foo.el is version x.y of that package, without having to add an extra directory inside ~/.emacs.d/elpa with adds a new entry in load-path. – PRouleau Jun 11 at 2:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.