4 Ce projet est un effort coopératif et nous avons besoin de votre aide pour
5 le faire grandir ! Contactez-nous sur @email{guix-devel@@gnu.org} et
6 @code{#guix} sur le réseau IRC Freenode. Nous accueillons les idées, les
7 rapports de bogues, les correctifs et tout ce qui pourrait aider le
8 projet. Nous apprécions particulièrement toute aide sur la création de
9 paquets (@pxref{Consignes d'empaquetage}).
11 @cindex code de conduite, des contributeurs
12 @cindex convention de contribution
13 Nous souhaitons fournir un environnement chaleureux, amical et sans
14 harcèlement pour que tout le monde puisse contribuer au mieux de ses
15 capacités. Pour cela notre projet a une « Convention de contribution »
16 adaptée de @url{http://contributor-covenant.org/}. Vous pouvez trouver une
17 version locale dans le fichier @file{CODE-OF-CONDUCT} dans l'arborescence
20 Les contributeurs n'ont pas besoin d'utiliser leur nom légal dans leurs
21 correctifs et leurs communications en ligne ; ils peuvent utiliser n'importe
22 quel nom ou pseudonyme de leur choix.
25 * Construire depuis Git:: The latest and greatest.
26 * Lancer Guix avant qu'il ne soit installé:: Astuces pour les hackers.
27 * La configuration parfaite:: Les bons outils.
28 * Style de code:: Hygiène du contributeur.
29 * Envoyer des correctifs:: Partager votre travail.
32 @node Construire depuis Git
33 @section Construire depuis Git
35 Si vous souhaitez travailler sur Guix lui-même, il est recommandé d'utiliser
36 la dernière version du dépôt Git :
39 git clone https://git.savannah.gnu.org/git/guix.git
42 Lors de la construction de Guix depuis un extrait, les paquets suivants sont
43 requis en plus de ceux mentionnés dans les instructions d'installation
47 @item @url{http://gnu.org/software/autoconf/, GNU Autoconf};
48 @item @url{http://gnu.org/software/automake/, GNU Automake};
49 @item @url{http://gnu.org/software/gettext/, GNU Gettext};
50 @item @url{http://gnu.org/software/texinfo/, GNU Texinfo};
51 @item @url{http://www.graphviz.org/, Graphviz};
52 @item @url{http://www.gnu.org/software/help2man/, GNU Help2man (facultatif)}.
55 La manière la plus simple de configurer un environnement de développement
56 pour Guix est, bien sûr, d'utiliser Guix ! La commande suivante démarre un
57 nouveau shell où toutes les dépendances et les variables d'environnements
58 appropriées sont configurés pour travailler sur Guix :
64 @xref{Invoquer guix environment}, pour plus d'information sur cette
65 commande. On peut ajouter des dépendances supplémentaires avec
69 guix environment guix --ad-hoc help2man git strace
72 Lancez @command{./bootstrap} pour générer l'infrastructure du système de
73 construction avec Autoconf et Automake. Si vous avez une erreur comme :
76 configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES
80 cela signifie probablement qu'Autoconf n'a pas pu trouver @file{pkg.m4} qui
81 est fournit par pkg-config. Assurez-vous que @file{pkg.m4} est
82 disponible. C'est aussi vrai pour l'ensemble de macros de @file{guile.m4}
83 fournies par Guile. Par exemple, si vous avez installé Automake dans
84 @file{/usr/local}, il ne cherchera pas les fichiers @file{.m4} dans
85 @file{/usr/share}. Dans ce case vous devez invoquer la commande suivante :
88 export ACLOCAL_PATH=/usr/share/aclocal
91 @xref{Macro Search Path,,, automake, The GNU Automake Manual}, pour plus
94 Ensuite, lancez @command{./configure} comme d'habitude. Assurez-vous de
95 passer @code{--localstatedir=@var{directory}} où @var{directory} est la
96 valeur @code{localstatedir} utilisée par votre installation actuelle
97 (@pxref{Le dépôt} pour plus d'informations à ce propos).
99 Finalement, vous devez invoquer @code{make check} pour lancer les tests
100 (@pxref{Lancer la suite de tests}). Si quelque chose échoue, jetez un œil
101 aux instructions d'installation (@pxref{Installation}) ou envoyez un message
102 à la list @email{guix-devel@@gnu.org}.
105 @node Lancer Guix avant qu'il ne soit installé
106 @section Lancer Guix avant qu'il ne soit installé
108 Pour garder un environnement de travail sain, il est utile de tester les
109 changement localement sans les installer pour de vrai. Pour pouvoir
110 distinguer votre rôle « d'utilisateur final » de celui parfois haut en
111 couleur de « développeur ».
113 Pour cela, tous les outils en ligne de commande sont utilisables même sans
114 avoir lancé @code{make install}. Vous devez pour cela préfixer chaque
115 commande par @command{./pre-inst-env} (le script @file{pre-inst-env} se
116 trouve dans le répertoire de plus haut niveau de l'arborescence des sources
117 de Guix) comme cela@footnote{L'option @option{-E} de @command{sudo} garantie
118 que @code{GUILE_LOAD_PATH} est bien paramétré pour @command{guix-daemon} et
119 les outils qu'il utilise puissent trouver les modules Guile dont ils ont
123 $ sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild
124 $ ./pre-inst-env guix build hello
128 De même, pour une session Guile qui utilise les modules Guix :
131 $ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'
138 @cindex read-eval-print loop
139 @dots{} et pour un REPL (@pxref{Using Guile Interactively,,, guile, Guile
143 $ ./pre-inst-env guile
144 scheme@@(guile-user)> ,use(guix)
145 scheme@@(guile-user)> ,use(gnu)
146 scheme@@(guile-user)> (define snakes
148 (lambda (package lst)
149 (if (string-prefix? "python"
150 (package-name package))
154 scheme@@(guile-user)> (length snakes)
158 Le script @command{pre-inst-env} paramètre toutes les variables
159 d'environnement nécessaires, dont @env{PATH} et @env{GUILE_LOAD_PATH}.
161 Remarquez que @command{./pre-inst-env guix pull} ne met @emph{pas} à jour
162 l'arborescence des sources locale ; il met seulement à jour le lien
163 symbolique @file{~/.config/guix/latest} (@pxref{Invoquer guix pull}). Lancez
164 @command{git pull} à la place si vous voulez mettre à jour votre
165 arborescence des sources locale@footnote{Si vous voulez paramétrer
166 @command{guix} pour qu'il utilise votre dépôt Git, vous pouvez faire pointer
167 le lien symbolique @file{~/.config/guix/latest} vers le répertoire contenant
168 ce dépôt. Si vous le seul utilisateur du système, vous pouvez aussi
169 considérer faire pointer le lien symbolique @file{/root/.config/guix/latest}
170 vers @file{~/.config/guix/latest} ; comme ça root aura toujours la même
171 commande @command{guix} que votre utilisateur}.
174 @node La configuration parfaite
175 @section La configuration parfaite
177 La configuration parfaite pour travailler sur Guix est simplement la
178 configuration parfaite pour travailler en Guile (@pxref{Using Guile in
179 Emacs,,, guile, Guile Reference Manual}). Tout d'abord, vous avez besoin de
180 mieux qu'un éditeur de texte, vous avez besoin de
181 @url{http://www.gnu.org/software/emacs, Emacs}, amélioré par le superbe
182 @url{http://nongnu.org/geiser/, Geiser}.
184 Geiser permet le développement interactif et incrémental depuis Emacs : la
185 compilation du code et son évaluation depuis les buffers, l'accès à la
186 documentation en ligne (docstrings), la complétion sensible au contexte,
187 @kbd{M-.} pour sauter à la définition d'un objet, un REPL pour tester votre
188 code, et bien plus (@pxref{Introduction,,, geiser, Geiser User
189 Manual}). Pour travailler confortablement sur Guix, assurez-vous de modifier
190 le chemin de chargement de Guile pour qu'il trouve les fichiers source de
194 ;; @r{Si l'extrait est dans ~/src/guix.}
195 (with-eval-after-load 'geiser-guile
196 (add-to-list 'geiser-guile-load-path "~/src/guix"))
199 To actually edit the code, Emacs already has a neat Scheme mode. But in
200 addition to that, you must not miss
201 @url{http://www.emacswiki.org/emacs/ParEdit, Paredit}. It provides
202 facilities to directly operate on the syntax tree, such as raising an
203 s-expression or wrapping it, swallowing or rejecting the following
206 @cindex extraits de code
208 @cindex réduire la quantité de code commun
209 Nous fournissons aussi des modèles pour les messages de commit git communs
210 et les définitions de paquets dans le répertoire @file{etc/snippets}. Ces
211 modèles s'utilisent avec @url{http://joaotavora.github.io/yasnippet/,
212 YASnippet} pour développer des chaînes courtes de déclenchement en extraits
213 de texte interactifs. Vous pouvez ajouter le répertoire des modèles dans la
214 variables @var{yas-snippet-dirs} d'Emacs.
217 ;; @r{Si l'extrait est dans ~/src/guix.}
218 (with-eval-after-load 'yasnippet
219 (add-to-list 'yas-snippet-dirs "~/src/guix/etc/snippets"))
222 Les extraits de messages de commit dépendent de @url{https://magit.vc/,
223 Magit} pour afficher les fichiers sélectionnés. Lors de la modification d'un
224 message de commit, tapez @code{add} suivi de @kbd{TAB} pour insérer un
225 modèle de message de commit pour ajouter un paquet ; tapez @code{update}
226 suivi de @kbd{TAB} pour insérer un modèle pour la mise à jour d'un paquet.
228 L'extrait principal pour @code{scheme-mode} est lancé en tapant
229 @code{package…} suivi par @kbd{TAB}. Cet extrait insère aussi la chaîne de
230 déclenchement @code{origin…}, qui peut aussi être étendue. L'extrait
231 @code{origin} lui-même peut aussi insérer des chaînes de déclenchement qui
232 finissent sur @code{…}, qui peuvent aussi être étendues.
236 @section Style de code
238 En général notre code suit le Standard de Code GNU (@pxref{Top,,, standards,
239 GNU Coding Standards}). Cependant, il ne parle pas beaucoup de Scheme, donc
240 voici quelques règles supplémentaires.
243 * Paradigme de programmation:: Comment composer vos éléments.
244 * Modules:: Où stocker votre code ?
245 * Types de données et reconnaissance de motif:: Implémenter des
246 structures de données.
247 * Formatage du code:: Conventions d'écriture.
250 @node Paradigme de programmation
251 @subsection Paradigme de programmation
253 Le code Scheme dans Guix est écrit dans un style purement fonctionnel. Le
254 code qui s'occupe des entrées-sorties est une exception ainsi que les
255 procédures qui implémentent des concepts bas-niveau comme la procédure
261 Les modules Guile qui sont sensés être utilisés du côté de la construction
262 doivent se trouver dans l'espace de nom @code{(guix build @dots{})}. Ils ne
263 doivent pas se référer à d'autres modules Guix ou GNU. Cependant il est
264 correct pour un module « côté hôte » de dépendre d'un module coté
267 Les modules qui s'occupent du système GNU général devraient se trouver dans
268 l'espace de nom @code{(gnu @dots{})} plutôt que @code{(guix @dots{})}.
270 @node Types de données et reconnaissance de motif
271 @subsection Types de données et reconnaissance de motif
273 La tendance en Lisp classique est d'utiliser des listes pour tout
274 représenter et de naviguer dedans « à la main ( avec @code{car}, @code{cdr},
275 @code{cadr} et compagnie. Il y a plusieurs problèmes avec ce style,
276 notamment le fait qu'il soit dur à lire, source d'erreur et un obstacle aux
277 rapports d'erreur bien typés.
279 Le code de Guix devrait définir des types de données appropriées (par
280 exemple, avec @code{define-record-type*}) plutôt que d'abuser des listes. En
281 plus, il devrait utiliser la recherche de motifs, via le module Guile
282 @code{(ice-9 match)}, surtout pour rechercher dans des listes.
284 @node Formatage du code
285 @subsection Formatage du code
287 @cindex formater le code
288 @cindex style de code
289 Lorsque nous écrivons du code Scheme, nous suivons la sagesse commune aux
290 programmeurs Scheme. En général, nous suivons les
291 @url{http://mumble.net/~campbell/scheme/style.txt, règles de style de
292 Riastradh}. Ce document décrit aussi les conventions utilisées dans le code
293 de Guile. Il est bien pensé et bien écrit, alors n'hésitez pas à le lire.
295 Certaines formes spéciales introduites dans Guix comme la macro
296 @code{substitute*} ont des règles d'indentation spécifiques. Elles sont
297 définies dans le fichier @file{.dir-locals.el} qu'Emacs utilise
298 automatiquement. Remarquez aussi qu'Emacs-Guix fournit le mode
299 @code{guix-devel-mode} qui indente et colore le code Guix correctement
300 (@pxref{Development,,, emacs-guix, The Emacs-Guix Reference Manual}).
302 @cindex indentation, du code
303 @cindex formatage, du code
304 Si vous n'utilisez pas Emacs, assurez-vous que votre éditeur connaisse ces
305 règles. Pour indenter automatiquement une définition de paquet, vous pouvez
309 ./etc/indent-code.el gnu/packages/@var{file}.scm @var{package}
313 Cela indente automatiquement la définition de @var{package} dans
314 @file{gnu/packages/@var{file}.scm} en lançant Emacs en mode commande. Pour
315 indenter un fichier complet, n'indiquez pas de second argument :
318 ./etc/indent-code.el gnu/services/@var{file}.scm
321 Nous demandons que toutes les procédure de premier niveau contiennent une
322 chaîne de documentation. Ce pré-requis peut être relâché pour les procédures
323 privées simples dans l'espace de nom @code{(guix build @dots{})} cependant.
325 Les procédures ne devraient pas avoir plus de quatre paramètres
326 positionnés. Utilisez des paramètres par mot-clefs pour les procédures qui
327 prennent plus de quatre paramètres.
330 @node Envoyer des correctifs
331 @section Envoyer des correctifs
333 Le développement se fait avec le système de contrôle de version Git. Ainsi,
334 l'accès au dépôt n'est pas strictement nécessaire. Nous accueillons les
335 contributions sous forme de correctifs produits par @code{git format-patch}
336 envoyés sur la liste de diffusion @email{guix-patches@@gnu.org}.
338 Cette liste de diffusion est gérée par une instance Debbugs accessible à
339 l'adresse @uref{https://bugs.gnu.org/guix-patches}, qui nous permet de
340 suivre les soumissions. Chaque message envoyé à cette liste se voit
341 attribuer un numéro de suivi ; les gens peuvent ensuite répondre à cette
342 soumission en envoyant un courriel à @code{@var{NNN}@@debbugs.gnu.org}, où
343 @var{NNN} est le numéro de suivi (@pxref{Envoyer une série de correctifs}).
345 Veuillez écrire les messages de commit dans le format ChangeLog
346 (@pxref{Change Logs,,, standards, GNU Coding Standards}) ; vous pouvez
347 regarder l'historique des commits pour trouver des exemples.
349 Avant de soumettre un correctif qui ajoute ou modifie la définition d'un
350 paquet, veuillez vérifier cette check-list :
354 Si les auteurs du paquet logiciel fournissent une signature cryptographique
355 pour l'archive, faîtes un effort pour vérifier l'authenticité de
356 l'archive. Pour un fichier de signature GPG détaché, cela se fait avec la
357 commande @code{gpg --verify}.
360 Prenez un peu de temps pour fournir un synopsis et une description adéquats
361 pour le paquet. Voir @xref{Synopsis et descriptions} pour quelques lignes
365 Lancez @code{guix lint @var{paquet}}, où @var{paquet} est le nom du nouveau
366 paquet ou du paquet modifié, et corrigez les erreurs qu'il rapporte
367 (@pxref{Invoquer guix lint}).
370 Assurez-vous que le paquet se construise sur votre plate-forme avec
371 @code{guix build @var{paquet}}.
374 @cindex construction groupée
375 Assurez-vous que le paquet n'utilise pas de copie groupée d'un logiciel déjà
376 disponible dans un paquet séparé.
378 Parfois, les paquets incluent des copie du code source de leurs dépendances
379 pour le confort de leurs utilisateurs. Cependant, en tant que distribution,
380 nous voulons nous assurer que ces paquets utilisent bien les copient que
381 nous avons déjà dans la distribution si elles existent. Cela améliore
382 l'utilisation des ressources (la dépendance n'est construite et stockée
383 qu'une seule fois) et permet à la distribution de faire des changements
384 transversaux comme appliquer des correctifs de sécurité pour un paquet donné
385 depuis un unique emplacement et qu'ils affectent tout le système, ce
386 qu'empêchent les copies groupées.
389 Regardez le profile rapporté par @command{guix size} (@pxref{Invoquer guix size}). Cela vous permettra de remarquer des références à d'autres paquets
390 qui ont été retenus. Il peut aussi aider à déterminer s'il faut découper le
391 paquet (@pxref{Des paquets avec plusieurs résultats}) et quelle dépendance
392 facultative utiliser.
395 Pour les changements important, vérifiez que les paquets qui en dépendent
396 (s'ils existent) ne sont pas affectés par le changement ; @code{guix refresh
397 --list-dependant @var{paquet}} vous aidera (@pxref{Invoquer guix refresh}).
399 @c ===========================================================================
401 @c This file was generated with po4a. Translate the source file.
403 @c ===========================================================================
404 @c See <https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html>.
405 @cindex stratégie de branche
406 @cindex stratégie de planification des reconstructions
407 Suivant le nombre de paquets dépendants et donc le nombre de reconstruction
408 induites, les commits vont vers des branches différentes, suivant ces
412 @item 300 paquets dépendants ou moins
413 branche @code{master} (changements non-disruptifs).
415 @item entre 300 et 1 200 paquets dépendants
416 branche @code{staging} (changemets non-disruptifs). Cette branche devrait
417 être fusionnées dans @code{master} tous les 3 semaines. Les changements par
418 thèmes (par exemple une mise à jour de la pile GNOME) peuvent aller dans une
419 branche spécifique (disons, @code{gnome-updates}).
421 @item plus de 1 200 paquets dépendants
422 branche @code{core-updates} (peut inclure des changements majeurs et
423 potentiellement disruptifs). Cette branche devrait être fusionnée dans
424 @code{master} tous les 2,5 mois environ.
427 Toutes ces branches sont gérées par notre ferme de construction et
428 fusionnées dans @code{master} une fois que tout a été construit
429 correctement. Cela nous permet de corriger des problèmes avant qu'ils
430 n'atteignent les utilisateurs et réduit la fenêtre pendant laquelle les
431 binaires pré-construits ne sont pas disponibles.
434 @cindex déterminisme, du processus de construction
435 @cindex construction reproductibles, vérification
436 Vérifiez si le processus de construction du paquet est déterministe. Cela
437 signifie typiquement vérifier qu'une construction indépendante du paquet
438 renvoie exactement le même résultat que vous avez obtenu, bit à bit.
440 Une manière simple de le faire est de reconstruire le paquet plusieurs fois
441 à la suite sur votre machine (@pxref{Invoquer guix build}) :
444 guix build --rounds=2 mon-paquet
447 Cela est suffisant pour trouver une classe de non-déterminisme commune,
448 comme l'horodatage ou des sorties générées aléatoirement dans le résultat de
451 Une autre option consiste à utiliser @command{guix challenge}
452 (@pxref{Invoquer guix challenge}). Vous pouvez lancer la commande une fois
453 que les paquets ont été commités et construits par @code{hydra.gnu.org} pour
454 vérifier s'il obtient le même résultat que vous. Mieux encore : trouvez une
455 autre machine qui peut le construire et lancez @command{guix publish}. Puis
456 la machine distante est sûrement différente de la vôtre, cela peut trouver
457 des problèmes de non-déterminisme liés au matériel — par exemple utiliser
458 une extension du jeu d'instruction — ou du noyau du système d'exploitation —
459 par exemple se reposer sur @code{uname} ou les fichiers de @file{/proc}.
462 Lorsque vous écrivez de la documentation, utilisez une formulation au genre
463 neutre lorsque vous vous référez à des personnes, comme le
464 @uref{https://fr.wikipedia.org/wiki/They_singulier, ``they''@comma{}
465 ``their''@comma{} ``them'' singulier} (en anglais).
468 Vérifiez que votre correctif contienne seulement un ensemble de changements
469 liés. Grouper des changements non liés ensemble rend la revue plus difficile
472 Ajouter plusieurs paquet ou une mise à jour d'un paquet avec des corrections
473 dans ce paquet sont des exemples de changements sans rapport.
476 Suivez nos règles de formatage de code, éventuellement en lançant le script
477 @command{et/indent-code.el} pour le faire automatiquement (@pxref{Formatage
482 Lorsque vous envoyez un correctif à la liste de diffusion, utilisez
483 @samp{[PATCH] @dots{}} comme sujet. Vous pouvez utiliser votre client de
484 courriel ou la commande @command{git send-email} (@pxref{Envoyer une série
485 de correctifs}). Nous préférons recevoir des correctifs en texte brut, soit
486 en ligne, soit en pièce-jointe MIME. Nous vous conseillons de faire
487 attention si votre client de courriel change par exemple les retours à la
488 ligne ou l'indentation, ce qui peut casser les correctifs.
490 Lorsqu'un bogue est résolu, veuillez fermer le fil en envoyant un courriel à
491 @email{@var{NNN}-done@@debbugs.gnu.org}.
493 @unnumberedsubsec Envoyer une série de correctifs
494 @anchor{Envoyer une série de correctifs}
495 @cindex série de correctifs
496 @cindex @code{git send-email}
497 @cindex @code{git-send-email}
499 @c Debbugs bug: https://debbugs.gnu.org/db/15/15361.html
500 Lorsque vous envoyez une série de correctifs (p.e. avec @code{git
501 send-email}), envoyez d'abord une premier message à
502 @email{guix-patches@@gnu.org} puis envoyez le reste des correctifs à
503 @email{@var{NNN}@@debbugs.gnu.org} pour vous assurer qu'ils seront groupés
504 ensemble. Voyez @uref{https://debbugs.gnu.org/Advanced.html, la
505 documentation de Debbugs} pour plus d'informations.