document recommended usage for package developers

[aspiers]

If I want to simultaneously use a package via el-get (e.g. for convenient and consistent installation across multiple machines) and help develop it, it's not immediately clear how to do this with el-get. It seems that by creating an entry with the same package name in el-get-sources, as long as I don't set the :type property, I can reuse the upstream recipe-authoring work (e.g. figuring out appropriate values for :build) but have local overrides for other values, e.g. :username, :pkgname, :branch etc. which will get merged into the upstream recipe definition.

So for example, if I want to hack on magit, setting el-get-sources to ((:name magit :pkgname "aspiers/magit")) results in the local clone of my magit fork. However there are still remaining questions:

• If I already had the upstream version of magit installed, how would I switch to my fork? Removing and reinstalling works, but is there a better way?
• The code still gets cloned to the same place (~/.emacs.d/el-get/magit). Is it safe to work on code from a repository stored there, or is it treated as a cache which could be unexpectedly wiped at certain points? What if I need the code to live outside ~/.emacs.d?)
• What if my alternative fork is available via a different mechanism to the original? For example, the upstream magit.rcp has :type set to github, but what if my fork is somewhere other than github, or not even in a git repository? Would I then have to take a full copy of the upstream recipe and modify it? That would prevent being able to track any upstream changes in the recipe's other properties (installation procedure etc.), although it could be argued that's a good thing I suppose.

I think it would be awesome if the user manual had a short chapter offering some recommended procedures for this kind of use case.

[dimitri]

That's a good idea, I will work on that when I find some time.

Basically either you do it with el-get-sources then can hack in ~/.emacs.d/el-get/package (I know contributors who do that), or you can have another full recipe found earlier in el-get-recipe-path. I don't think there's a way to put the package elsewhere other than moving it out of el-get management.

[aspiers]

I think it's cleaner to hack outside ~/.emacs.d/el-get because then there is no danger of el-get unexpectedly changing the repository you are working on. It would also safely allow rebuilding the whole of ~/.emacs.d/el-get without any loss of work.

It looks like adding a :url property to an entry in el-get-sources won't work for :type github packages, so presumably the only solution is to prepend a new entry to el-get-recipe-path and then create a recipe pointing to a local repo from there? In which case, why isn't el-get-recipe-path a defcustom?

Even if the only clean way to hack on sources currently available is to do it within ~/.emacs.d/el-get/$package, then I think that should be documented in a new chapter of the user manual, which could also link to this issue to make people aware it's a known issue. Thanks!

[yyr]

@aspiers

I think, as you said, it is better to have el-get-recipe-path customizable (or a new path variable with higher priority) and inform package developers to have local recipe files in that which point to local file system.

[aspiers]

Ah, actually there is a good reason for not having el-get-recipe-path customizable: #1164.

[aspiers]

Thinking about this a bit more ... The "create a recipe somewhere earlier in el-get-recipe-path which points to the local fork outside ~/.emacs.d/el-get" approach is actually not very useful, because every time you edit code in your local fork, you still have to do an el-get-update so that that code is copied back into ~/.emacs/el-get and reloaded. A better implementation would have el-get aware that the code is currently in flux and being developed locally outside ~/.emacs.d/el-get", meaning that an el-get-reload would re-evaluate it directly from the tree where it's being developed. Similarly, el-get-byte-compile would perform compilation in the development tree, not in a copy within ~/.emacs/el-get. This would probably require extending el-get-package-files and/or el-get-package-directory with some override mechanism. One possibility would be to add support for :inherit and :local-path properties to recipes which would allow a recipe to inherit values from a recipe of the same name in another directory later in el-get-recipe-path, and override the value of el-get-package-directory.

For anyone who is familiar with bundler, basically what I'm aiming for here is very similar to its local git repository override feature (see the "Local git repositories" section of the bundle-config docs).

[aspiers]

Don't suppose there has been any progress on this in the last couple of years?

[dimitri]

None from me, for lack of time to spend here :(