all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: Dmitry Bogatov <KAction@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: Multiple versions
Date: Sun, 27 Dec 2015 13:28:47 +0100	[thread overview]
Message-ID: <87si2o3wjk.fsf@elephly.net> (raw)
In-Reply-To: <20151227104109.GA11215@sagulo>


Dmitry Bogatov <KAction@gnu.org> 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

  reply	other threads:[~2015-12-27 12:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-26 23:02 Multiple versions Dmitry Bogatov
2015-12-27  5:26 ` Pjotr Prins
2015-12-27  9:20   ` Dmitry Bogatov
2015-12-27  9:48     ` Andreas Enge
2015-12-27 10:41       ` Dmitry Bogatov
2015-12-27 12:28         ` Ricardo Wurmus [this message]
2015-12-27 12:41     ` Pjotr Prins
2015-12-27 14:40       ` Dmitry Bogatov
2015-12-27 15:41         ` Ricardo Wurmus
2015-12-27 16:41           ` Dmitry Bogatov
2015-12-27 15:58         ` Pjotr Prins
2015-12-29 15:21     ` Ludovic Courtès
2015-12-27 14:11 ` Alex Kost
2015-12-27 16:47   ` Emacs load path (was: Re: Multiple versions) Dmitry Bogatov
2015-12-27 21:42     ` Emacs load path Alex Kost
  -- strict thread matches above, loose matches on Subject: below --
2016-07-16 13:57 multiple versions Vincent Legoll
2016-07-16 20:49 ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87si2o3wjk.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=KAction@gnu.org \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.