Re: Multiple versions

[Ricardo Wurmus]

Dmitry Bogatov <address@hidden> writes:

>> Then there is the combinatorial explosion. If you have 20 libraries in
>> 10 versions each that are needed to build a derived binary, then there
>> will be 10^20 possible combinations. Which of them would you like to
>> support?
>
> Build binaries with latest versions of libraries and compilers.
>
>> Our general policy is to keep only the latest version, except for special
>> cases where people see a point in keeping older versions (script languages,
>> libraries like qt with two major versions supported in parallel, and so on).
>
>> What is your use case? If you want reproducibility, it could make sense
>> to simply stick to a given git commit. If you just need a particular older
>
> My use case is that I want to be able to install every version of
> any haskell library and every version of ghc for testing purposes.
>
> For example, I write code, that uses ghc-7.10 with lens-4.13. Will it
> work with ghc-7.6(Debian stable) and lens-4.1.2.1? This versions are
> important to me, but some other person may have another reference.

This doesn’t seem to be a useful way for the Guix project as such to use
our limited resources.

However, Guix is a library and packages are just Scheme values.  You can
write a procedure that recursively replaces the GHC value throughout the
graph of a given package.  Then you can build variants of the package
graph that use a different version of GHC.

> Yes, there is combinatorics, but not too terrible. ~1000 packages, 4 ghc
> versions -> 4000 <package> variables.

This is only for different versions of GHC, but not different versions
of packages such as lens.

> Ah, and I do not propose to actually support, for example,
> ghc7.6-lens-4.13. If it fails to build, that it is dropped.

Then it may be better to do this on a machine dedicated to the task of
testing Haskell package combinations.

> Some kind of automatization and integration with hydra would
> be useful.

Using our main Hydra instance for this seems like wasting resources that
could be used for other purposes more closely related to the goals of
the Guix project.

~~ Ricardo