[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Multiple versions
From: |
Ricardo Wurmus |
Subject: |
Re: Multiple versions |
Date: |
Sun, 27 Dec 2015 13:28:47 +0100 |
User-agent: |
mu4e 0.9.13; emacs 24.5.1 |
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
- Multiple versions, Dmitry Bogatov, 2015/12/26
- Re: Multiple versions, Pjotr Prins, 2015/12/27
- Re: Multiple versions, Pjotr Prins, 2015/12/27
- Re: Multiple versions, Dmitry Bogatov, 2015/12/27
- Re: Multiple versions, Ricardo Wurmus, 2015/12/27
- Re: Multiple versions, Dmitry Bogatov, 2015/12/27
- Re: Multiple versions, Pjotr Prins, 2015/12/27
- Re: Multiple versions, Ludovic Courtès, 2015/12/29
Re: Multiple versions, Alex Kost, 2015/12/27