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
next prev parent 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.