Recipe override should be able to set type

[dabrahams]

Great. Seems to me that recipe override might easily need to set the type. For example, if I fork some cvs-based package to github and make some modifications that haven't been accepted upstream yet, I want to change the type and the URL, and nothing else. In fact, I'm pretty sure that's about to happen for me with wanderlust, in fact.

[dimitri]

Well, how do you tell apart a merge situation against a local-only (I mean embedded into el-get-sources) definition then?

Also, please remember that you have el-get-recipe-path to tweak to your content. The first recipe file found in this paths list will get used, no other. That seems to be the lever you're looking here.

[dabrahams]

Well, how do you tell apart a merge situation against a local-only (I mean embedded into el-get-sources) definition then?

By a different mechanism, naturally. I suggest deprecating the no-type mechanism (I don't mean removing support today, just put users on notice) and allow an :inherit t keyword to indicate an override.

Also, please remember that you have el-get-recipe-path to tweak to your content. The first recipe file found in this paths list will get used, no other.

If none other will be used, what do you mean by

If your property list is missing the :type property, then it's
merged with the recipe one, so that you can override any
definition provided by `el-get' recipes locally.

oh... maybe you mean that overrides only work for property lists in el-get-sources, but if I have a recipe, it can't override bits of other recipes?

[dimitri]

Exactly, that's what we have now.