|
From: | Vijayalakshmi Vedantham |
Subject: | Re: Internship on Improve the user experience for the "guix package" command line tool (Outreachy) |
Date: | Mon, 19 Mar 2018 22:28:27 +0530 |
Hi Vijayalakshmi,
Thanks again for your first successful contribution to Guix! Don’t
forget to record your contribution on the Outreachy website.
You may have noticed that there was a lot of output when running “guix
build r-abbyyr”. The same is true when running “guix package -i
r-abbyyr”, which will install the package into your default profile
after building it (when no pre-built package is offered by our build
farm). The project’s goal – among others — is to make all this output
less intimidating, especially when using “guix package -i”.
> I'm excited to continue working. What other tasks do you have in mind?
> Should I add more packages or do something else?
Let’s take a closer look at the package you created.
The whole thing is a variable definition. You defined the public
variable “r-abbyyr” and bound a package value to it. In Scheme that’s
how you define a variable with the name “a” and a value of 12:
(define a 12)
Your package definition is not so different from that:
(define r-abbyyr (package …))
In Scheme whatever thing comes first in a parenthetical _expression_ is
usually either a procedure or a special form. If it is a procedure,
everything that follows is an argument. Here’s an example:
(+ 1 2 3 4 5 10)
The first element in this _expression_ is “+”, which is a procedure that
adds its arguments. All the numbers that follow are arguments to that
procedure. When this _expression_ is evaluated, the result is the sum of
all these numbers: 15.
“package” is a special form that takes a bunch of fields and values and
produces a package object. Let’s look at one particular field that the
“package” form provides: the “build-system” field.
As an R package “r-abbyyr” used the “r-build-system”. The value of the
“r-build-system” variable is defined in “guix/build-system/r.scm”, and
it completely describes how an R package is to be built with Guix. We
support more build systems in Guix, but all of them have the same
features in common: they all provide so-called build phases that are
executed in order. Each build phase is just a procedure.
As a next task I would suggest to browse the source code of Guix to see
what build systems are offered by Guix. The build phases for the R
build system, for example, are defined as “%standard-phases” in
“guix/build/r-build-system.scm”.
Maybe you can try to create a package definition for another application
that uses a different build system. How about a simple Python package
from pypi? Where are the build phases for a Python package defined?
What is the build system that is used for Python packages?
PS: what do you think about Cc-ing the public address@hidden mailing
list for future communication? The benefit is that this list is
archived and accessible by anyone, such as future contributors. And in
case I make a mistake and explain something poorly others will have a
chance to correct me :)
0002-gnu-Add-python-logwrap.patch
Description: Text Data
[Prev in Thread] | Current Thread | [Next in Thread] |