1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
|
# CHICKEN {#sec-chicken}
[CHICKEN](https://call-cc.org/) is a Scheme compiler. It includes an
interactive mode and a custom package format, "eggs". CHICKEN 5 is
[R⁵RS](https://schemers.org/Documents/Standards/R5RS/HTML/)-compliant, whereas
CHICKEN 6 targets
[R⁷RS](https://standards.scheme.org/official/r7rs.pdf).
## Package Sets {#sec-chicken-package-sets}
Each major release of CHICKEN has its own package set, because eggs are
compiled against a specific binary version of the compiler and cannot be shared
between releases:
* `chickenPackages_5` — CHICKEN 5, and the set the unversioned attributes
(`chicken`, `chickenPackages`, `eggDerivation`, `fetchegg`) point at.
* `chickenPackages_6` — CHICKEN 6.
* `chickenPackages_4` — CHICKEN 4; kept for the few packages that still need
it and maintained on a best-effort basis.
Each set provides `chicken`, `eggDerivation`, `fetchegg` and an `chickenEggs`
attrset of eggs published for that release. Note that upstream has not ported
every egg to CHICKEN 6 yet, so `chickenPackages_6.chickenEggs` is considerably
smaller than its CHICKEN 5 counterpart.
CHICKEN 5 and 6 are built from the same expressions, in
`pkgs/development/compilers/chicken/common/`; the release directories next to
it hold only what differs between releases, which is the compiler's version and
its egg set. CHICKEN 4 predates that arrangement and stands on its own.
## Using Eggs {#sec-chicken-using}
Eggs described in Nixpkgs are available inside the
`chickenPackages.chickenEggs` attrset. Including an egg as a build input is
done in the typical Nix fashion. For example, to include support for [SRFI
189](https://srfi.schemers.org/srfi-189/srfi-189.html) in a derivation, one
might write:
```nix
{
buildInputs = [
chicken
chickenPackages.chickenEggs.srfi-189
];
}
```
Both `chicken` and its eggs have a setup hook which configures the environment
variables `CHICKEN_INCLUDE_PATH` and `CHICKEN_REPOSITORY_PATH`.
## Updating Eggs {#sec-chicken-updating-eggs}
For CHICKEN 5 and 6, the egg set is generated from upstream's list of latest
egg releases, so there is no list of eggs to curate in Nixpkgs: every egg
published for that release is included. The generated metadata lives in the
release directory's `deps.toml`, and is regenerated by running the shared
`update.sh` script with the release to update:
```
$ cd pkgs/development/compilers/chicken/common/
$ ./update.sh 6
```
This clones upstream's `eggs-<major>-latest` repository, prefetches each egg
tarball and converts the egg metadata into `deps.toml`. Do not edit
`deps.toml` by hand.
Eggs that need extra native dependencies or other fixups are patched up in
`overrides.nix` in the release directory; the entries there are keyed by egg
name and applied automatically by `eggDerivation`.
## Adding Eggs {#sec-chicken-adding-eggs}
CHICKEN 4 predates the workflow above: its much smaller set is generated with
[egg2nix](https://github.com/the-kenny/egg2nix) from a hand-written list of
eggs, so eggs have to be added explicitly. The list is
`pkgs/development/compilers/chicken/4/eggs.scm`; the first section lists eggs
which are required by `egg2nix` itself, all other eggs go into the second
section. After editing, regenerate the set:
```
$ nix-shell -p chickenPackages_4.egg2nix
$ cd pkgs/development/compilers/chicken/4/
$ egg2nix eggs.scm > eggs.nix
```
`egg2nix` resolves one collection of eggs with mutually-compatible versions, so
adding an egg may update existing ones. To keep those changes separate,
regenerate the set before adding more eggs.
## Override Scope {#sec-chicken-override-scope}
The chicken package and its eggs, respectively, reside in a scope. This means,
the scope can be overridden to affect other packages in it.
This example shows how to use a local copy of `srfi-180` and have it affect
all the other eggs:
```nix
let
myChickenPackages = pkgs.chickenPackages.overrideScope (
self: super: {
# The chicken package itself can be overridden to affect the whole ecosystem.
# chicken = super.chicken.overrideAttrs {
# src = ...
# };
chickenEggs = super.chickenEggs.overrideScope (
eggself: eggsuper: {
srfi-180 = eggsuper.srfi-180.overrideAttrs {
# path to a local copy of srfi-180
src = <...>;
};
}
);
}
);
# Here, `myChickenPackages.chickenEggs.json-rpc`, which depends on `srfi-180` will use
# the local copy of `srfi-180`.
in
<...>
```
|
