Recipe should support stable and dev versions of a package

[asok]

Shouldn't el-get be able to support defining 2 versions of a package in the recipe? For example support for ruby in emacs is not so perfect. There's a pull request for updating ruby related recipes to use non-stable packages. The issue is that maybe someone prefers to use stable versions of packages.
I think it would be a nice addition.

[dimitri]

el-get is already able to use more than 1 directory where to lookup for recipes, see el-get-recipe-path. So maybe we could have a "testing" path and a "stable" path, and we can provide more than one recipe per package then. Users would have to change the path to implement their prefering the stable or the testing version.

What do you think?

[yyr]

I don't know if its a good idea to have wholesale test and stable setup. what if user wants to use a couple of random packages test version and stable rest of them.?

[asok]

So the convention might be that the stable package would be named foobar and the test version foobar-test. So user would be installing stable version by default and if he wants to use test version he would have to state it explicitly.
I think it's good enough.
Though instead of test word I would use something else. Like unstable or dev for example.

[DarwinAwardWinner]

Simply making completely separate recipes for stable and devel versions still leaves a lot of unsolved issues, though. If A depends on B, what does A-devel depend on?

What if each recipe could have a :variant property, and you could specify a variant in your el-get-sources? So in one recipe directory, you might have:

(:name a
 :type http
 ...
 :variant stable)

and in another recipe directory you might have:

(:name a
 :type git
 ...
 :variant devel)

Then in you el-get-sources, you can put (:name a :variant devel) for the unstable version and (:name a :variant stable), and el-get will choose the appropriate variant of the recipe. Of course, maybe instead of separate directories it would be sublists within a single recipe, but the idea is the same. Ultimately, though, the most general answer is "if you don't like the provided recipes, write your own.

[dimitri]

Good point about the dependencies, and this :variant looks too complex an implementation for the problem at hand. Currently only the :name property works that way (matching rather than overloading). That said, I don't think that "write your own recipe" is going to continue to work well enough. I feel that if we don't answer this need we might see a fork of el-get containing only "stable" recipes, and I wouldn't enjoy that position.

So maybe the :variant is our best move here. Any other idea?

[DarwinAwardWinner]

How about having separate directories for stable and devel versions, combined with the ability to specify a recipe path for each recipe? Then you could run mostly stable but set the path to the devel directory for just a few recipes. No matter what we do here, something has to change in the recipe lookup process, unless we go with the "write your own" solution.

[tkf]

How about let user do some like this for using developmental version?:

(setq el-get-sources
      '((:name PACKAGE :type builtin :depends PACKAGE-dev)))

Here we have PACKAGE.rcp (stable version) and PACKAGE-DEV.rcp (developmental version). This way, we don't need extra machinery for recipe lookup. We can reduce the above configuration by having :type dev for short hand notation.

There will be problem if we allow developmental package to depend on other developmental packages. We need to handle that case explicitly if we go this way.

[dimitri]

It seems that we need to move to multiple variants support here. I wonder if we should prefer having them in separate directories or as separate list entries in the recipe file. I think we will want to be able to merge a variant with a base recipe so as not to duplicate common entries, much like we do with el-get-sources already, and that hints me into avoiding the multiple directory solution altogether.

[DarwinAwardWinner]

Supporting recipe variants is going to add a lot of complexity to el-get, and is also likely going to make recipes fail unpredictably if version dependencies between packages are violated by particular combinations of stable and devel installs. We need to decide if this is important enough to justify all that.

Thoughts?

[dimitri]

What about forcing the dependencies to be solved only using recipes of the same variant? That would mean that if package a variant devel depends on package b variant stable you need to duplicate package b so that you have a devel variant of it.

The other way would be to force variants into a list of known variants and implement a sorting operator so that devel can depend on stable but not the other way around.

I still think that we should find a solution to the bleeding edge versus stable distribution with el-get, I'm not sure about the variants idea, but the only other one I can think about would be to choose that at the distribution level rather than per-package, and I still feel we can do better than that... Maybe not, though.

[tkf]

Sometime you need to pick up particular version of Emacs lisp packages and freeze them using :checksum. I don't think el-get is responsible for making sure that all packages are compatible. It think it is job for ELPA.

Off topic, but it would be nice if we can easily share working set of checksums for Emacs lisp packages...

[rrthomas]

It would be nice to have some more decision on this. Recently, I've contributed several recipes and updates to recipes which use specific versions of the relevant package. As an el-get user, I want stable code in most packages, just as I do in packages installed from my distro. In a few in which I take a particular interest (bugs I want fixed, features I want) I may want bleeding-edge code.

Hence, I'd expect to see fixed-version recipes in stable releases of el-get, at least. Until the problem of loading multiple versions of a package can be solved, I can't really see how to also have bleeding-edge versions in general (as you might expect in the bleeding-edge el-get). I think a better model for now is Debian unstable, which includes recent versions of packages, but still ones that are expected to work with other versions in unstable. That means that all recipes can be of the same sort (other than ones that are essentially unversioned, like emacswiki recipes), and stable releases are (as now) snapshots of master (having recipes of two types would also cause a problem here).

Note that for those who want them, bleeding-edge recipes are usually very fast to construct, especially if they can use a "template" type like github, and users aren't likely to want many at a time. I'm quite happy making them myself when I need them.

[SamHasler]

It seems like issue #1142 would be a prerequisite for this.

[dimitri]

My view on el-get recipes is that whoever submits a Pull Request for a recipe is an actual user of the package and is proposing a version that is known to work, so I mostly accept the Pull Request. I don't want to make a stronger policy around it, I want to make it super easy to update recipes when they need to be updated, and I want to make it super easy to use another recipe source.

Note that it's already possible to maintain another repository of recipes and point el-get to it, using the el-get-recipe-path variable.