Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Could not retrieve cached recipe for package package #797
el-get version 18.104.22.168fc85a4
Thank you for writing such wonderful el-get, it makes my life
Recently, I found a problem about el-get.
This problem affected me when I intended to install slime.
I tried el-get-elpa-build-local-recipes, but it seems useless.
But after I el-get-remove the package named package, everything is OK.
added a commit
Jan 18, 2013
Well, I got the same error. I must add that something seems fundamentally wrong about triggering a hard error when data is missing from a cache. That's expected to happen with caches; the usual response is to fetch the missing data into the cache automatically and proceed as if it was always there.
It's not a cache in that meaning of the term, it's a copy of the recipe as it were at the time when you installed the package. By definition when merging-in the new recipe definition, we have no other source where to find the recipe for the package as when you did install it the first time. As some upgrades are not compatible (switch from csv to git for example) we can not ignore the problem.
Another bug report that I don't know what do to with in the time I can allocate to it. Will try and see about it later, but without further information I doubt this bug report is useful enough to decide for anything.
Yes, I suppose I deserve the blame for calling it a cache when it's really not. I'm not exactly sure what the right term is. "Snapshot store"?
In any case, for every package that is installed, a recipe is supposed to be stored in the cache-that's-not-really-a-cache. This is because even if the recipe is later updated (or removed), the already-installed package needs to keep using the old recipe. In theory, it shouldn't be possible to have an installed package with a missing recipe snapshot. So, since this case should "never" happen, I guess we can do whatever we want when it happens. Currently we throw an error, which helps with debugging, but I would be in favor of changing that to a warning followed by using the latest available version of the recipe, on the possibility that it happens to have not changed.
Chances are that we will just fail later with an error that's harder to understand. It could be that the problem here is in the status reading functions that should transform the status file from the old to the new format and do exactly what you're saying then. Want to see about that?
@dabrahams, do you care enough to share your status file content?
We should probably change the error message to include the status entry for the offending package, as well as a recommendation for the user to remove and reinstall it, and we should make sure that packages can be removed without needing their recipes available (I believe this is the case).