Re: Parameterized packages

[zimoun]

On Thu, 16 Jan 2020 at 20:06, ison <address@hidden> wrote:
> On Wed, Jan 15, 2020 at 02:54:25PM +0100, zimoun wrote:

> > And what I was thinking is a mechanism to easily set some arguments to
> > the build-system; for example changing the compiler toolchain (say
> > replacing GCC by Clang/LLVM).
> >
> > Well, as I said, I do not know if it is related to "parametrized
> > packages" because I am not sure to understand the final aim for these
> > "parametrized packages". :-)

[...]

> That is, simplify the problem to the mere concept of passing arguments to
> functions and nothing more. Take the headless server example: some parameter
> is passed to a package such as
> '("-X")
> That package would then be entirely responsible for what to do with them. If
> the package decides not to pass the same parameters to its inputs then the
> inputs are simply built without any parameters.

I agree.

What I was trying to suggest and/or discuss is to see the build-system
as a function where the compiler toolset is one argument.

Let consider these "compilers" (associated with complete toolset for
"compiling"): OCaml@4.01, OCaml@4.07, OCaml@4.09, CPython@2.7,
CPython@3.5, CPython@3.6, PyPy (not yet in Guix), GCC@8, GCC@9,
Clang@8, Clang@9, etc.

Today, for one particular build system, the compiler is fixed. To use
another compiler than the default one, the trick is to have
'package-with-explicit' and each build-system has to provide
'package-with-<version>' where <version> is hard coded.

To be clear, the seed (bootstrap) fixes how the compilers OCaml@4.01,
OCaml@4.07, OCaml@4.09, CPython@2.7, CPython@3.5, CPython@3.6, PyPy
(not yet in Guix), GCC@8, GCC@9, Clang@8, Clang@9, etc are compiled.
Then, it is difficult to use them to compile a package with one of
them.

Do we end with 'package-with-ocaml4.01', 'package-with-ocaml4.07',
'package-with-ocaml4.09', 'package-with-python2',
'package-with-python3.5', 'package-with-python3.6',
'package-with-pypy', 'package-with-gcc8', 'package-with-gcc9', etc.?

Do the users have to write all these 'package-with-<version>'?
And if one wants to use CPython@3.5 and GCC@8, does they need to
define the package using:

(define-public my-foo
  (package-with-python3.5
       (package-with-gcc8 foo)))

?

I feel something is lacking.

And do not take me wrong, I am not suggesting that Guix should
maintain and ensure it works for all the combinations. The default is
already enough! :-)
And yes, it means potentially recompiling the world. Try to plot "guix
graph -t bag-emerged foo". ;-)


Why do I want that?

For example, a couple of software have been used to simulate complex
physical phenomena. Using the commit A -- which provides the seed A
and all compiling tools in the version X -- I get some results. Then
using the commit B -- which provided the seed B and all the compiling
tools in the version Y -- I get different results. Where does come
from the difference? From my couple of software which are not
reproducible? From round-off errors and floating point arithmetic
mess? Well, the most probable... but can I reduce the search space of
the difference? And I would like to be able to fix the seed to A, then
used the compiling tools in the version X and compare using this very
same seed A with the compiling tools in the version Y. Do the same
with seed B.

Well, it would ease comparison in the HPC world. :-)


It is not related to the "parametrized package" in the sense of flag
options. :-)

And I do not know if it make sense. What do you think?


All the best,
simon