dimitri/el-get — Issue #650: Use the recipe from the status file in more places
Author: DarwinAwardWinner
Created: 2012-03-08 02:04:08+00:00
State: open

We now have `el-get-init` using the saved recipe in the status file. But commands like `el-get-remove` should also be using this saved recipe. This would allow removing packages for which a recipe is currently unavailable, among other things.

Making this happen is not so easy. I have pushed a branch that does this for `el-get-remove`, and the diff is pretty large and spans 4 files: 8a140b5141c796b891b84c7c1ac8e9740101c776

I'm not submitting a pull request for this branch yet, because I don't think that my solution is really the right one. There's a lot of places where functions took a package name and called `el-get-package-def` on it, and I had to rearchitect all of them to accept either a package name or a full package source, and then I had to rearchitect the functions that call them to fetch the correct recipe from the status file before calling those functions.

At the heart of things, the problem is that simply specifying a package name is no longer sufficient to uniquely identify which recipe we want. We still need to choose between the one from the status file for installed packages, and the one in the recipe files. As I've said, the hack we've been using so far is to make functions that accept either a package name or a pre-fetched source, and then whenever we want the status recipe, we fetchit before calling these functions. Other options include:

* Adding an optional boolean argument to `el-get-package-def` that tells it to prefer the recipe from the status file, and then adding that same boolean argument to many other functions that call `el-get-package-def`, such as `el-get-load-path`.
* Whenever we want the status recipe, use `let` to dynamically bind `el-get-sources` to the list of recipes from the status file.

Do any of these sound reasonable? I'm leaning toward the dynamic binding solution, because it would be the least invasive. Any function that wants to work with the recipes of installed packages could just let-bind `el-get-sources` and all the functions it uses that depend on `el-get-package-def` will just work. I will see if I can push an alternate branch using this strategy.