summary refs log tree commit diff
path: root/doc/contributing.fr.texi
blob: 8900c7c704373b51cf3754094fb809add4f087d4 (plain) (blame)
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
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
@node Contribuer
@chapter Contribuer

Ce projet est un effort coopératif et nous avons besoin de votre aide pour
le faire grandir ! Contactez-nous sur @email{guix-devel@@gnu.org} et
@code{#guix} sur le réseau IRC Freenode.  Nous accueillons les idées, les
rapports de bogues, les correctifs et tout ce qui pourrait aider le projet.
Nous apprécions particulièrement toute aide sur la création de paquets
(@pxref{Consignes d'empaquetage}).

@cindex code de conduite, des contributeurs
@cindex convention de contribution
Nous souhaitons fournir un environnement chaleureux, amical et sans
harcèlement pour que tout le monde puisse contribuer au mieux de ses
capacités.  Pour cela notre projet a une « Convention de contribution »
adaptée de @url{http://contributor-covenant.org/}.  Vous pouvez trouver une
version locale dans le fichier @file{CODE-OF-CONDUCT} dans l'arborescence
des sources.

Les contributeurs n'ont pas besoin d'utiliser leur nom légal dans leurs
correctifs et leurs communications en ligne ; ils peuvent utiliser n'importe
quel nom ou pseudonyme de leur choix.

@menu
* Construire depuis Git::    toujours le plus récent.
* Lancer Guix avant qu'il ne soit installé::  Astuces pour les hackers.
* La configuration parfaite::  Les bons outils.
* Consignes d'empaquetage::  Faire grandir la distribution.
* Style de code::            Hygiène du contributeur.
* Envoyer des correctifs::   Partager votre travail.
@end menu

@node Construire depuis Git
@section Construire depuis Git

Si vous souhaitez travailler sur Guix lui-même, il est recommandé d'utiliser
la dernière version du dépôt Git :

@example
git clone https://git.savannah.gnu.org/git/guix.git
@end example

Lors de la construction de Guix depuis un extrait, les paquets suivants sont
requis en plus de ceux mentionnés dans les instructions d'installation
(@pxref{Prérequis}).

@itemize
@item @url{http://gnu.org/software/autoconf/, GNU Autoconf};
@item @url{http://gnu.org/software/automake/, GNU Automake};
@item @url{http://gnu.org/software/gettext/, GNU Gettext};
@item @url{http://gnu.org/software/texinfo/, GNU Texinfo};
@item @url{http://www.graphviz.org/, Graphviz};
@item @url{http://www.gnu.org/software/help2man/, GNU Help2man (facultatif)}.
@end itemize

La manière la plus simple de configurer un environnement de développement
pour Guix est, bien sûr, d'utiliser Guix ! La commande suivante démarre un
nouveau shell où toutes les dépendances et les variables d'environnements
appropriées sont configurés pour travailler sur Guix :

@example
guix environment guix
@end example

@xref{Invoquer guix environment}, pour plus d'information sur cette
commande.  On peut ajouter des dépendances supplémentaires avec
@option{--ad-hoc} :

@example
guix environment guix --ad-hoc help2man git strace
@end example

Lancez @command{./bootstrap} pour générer l'infrastructure du système de
construction avec Autoconf et Automake.  Si vous avez une erreur comme :

@example
configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES
@end example

@noindent
cela signifie probablement qu'Autoconf n'a pas pu trouver @file{pkg.m4} qui
est fournit par pkg-config.  Assurez-vous que @file{pkg.m4} est disponible.
C'est aussi vrai pour l'ensemble de macros de @file{guile.m4} fournies par
Guile.  Par exemple, si vous avez installé Automake dans @file{/usr/local},
il ne cherchera pas les fichiers @file{.m4} dans @file{/usr/share}.  Dans ce
case vous devez invoquer la commande suivante :

@example
export ACLOCAL_PATH=/usr/share/aclocal
@end example

@xref{Macro Search Path,,, automake, The GNU Automake Manual}, pour plus
d'information.

Ensuite, lancez @command{./configure} comme d'habitude.  Assurez-vous de
passer @code{--localstatedir=@var{directory}} où @var{directory} est la
valeur @code{localstatedir} utilisée par votre installation actuelle
(@pxref{Le dépôt} pour plus d'informations à ce propos).

Finalement, vous devez invoquer @code{make check} pour lancer les tests
(@pxref{Lancer la suite de tests}).  Si quelque chose échoue, jetez un œil
aux instructions d'installation (@pxref{Installation}) ou envoyez un message
à la liste @email{guix-devel@@gnu.org}.


@node Lancer Guix avant qu'il ne soit installé
@section Lancer Guix avant qu'il ne soit installé

Pour garder un environnement de travail sain, il est utile de tester les
changement localement sans les installer pour de vrai.  Pour pouvoir
distinguer votre rôle « d'utilisateur final » de celui parfois haut en
couleur de « développeur ».

Pour cela, tous les outils en ligne de commande sont utilisables même sans
avoir lancé @code{make install}.  Pour cela, vous devez d'abord avoir un
environnement avec toutes les dépendances disponibles (@pxref{Construire depuis Git}), puis préfixer chaque commande par @command{./pre-inst-env} (le script
@file{pre-inst-env} se trouve dans le répertoire de plus haut niveau de
l'arborescence des sources de Guix ; il est généré par
@command{./configure}) comme cela@footnote{L'option @option{-E} de
@command{sudo} garantie que @code{GUILE_LOAD_PATH} est bien paramétré pour
@command{guix-daemon} et pour que les outils qu'il utilise puissent trouver
les modules Guile dont ils ont besoin.} :

@example
$ sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild
$ ./pre-inst-env guix build hello
@end example

@noindent
De même, pour une session Guile qui utilise les modules Guix :

@example
$ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'

;;; ("x86_64-linux")
@end example

@noindent
@cindex REPL
@cindex read-eval-print loop
@dots{} et pour un REPL (@pxref{Using Guile Interactively,,, guile, Guile
Reference Manual})

@example
$ ./pre-inst-env guile
scheme@@(guile-user)> ,use(guix)
scheme@@(guile-user)> ,use(gnu)
scheme@@(guile-user)> (define snakes
                       (fold-packages
                         (lambda (package lst)
                           (if (string-prefix? "python"
                                               (package-name package))
                               (cons package lst)
                               lst))
                         '()))
scheme@@(guile-user)> (length snakes)
$1 = 361
@end example

Le script @command{pre-inst-env} paramètre toutes les variables
d'environnement nécessaires, dont @env{PATH} et @env{GUILE_LOAD_PATH}.

Remarquez que @command{./pre-inst-env guix pull} ne met @emph{pas} à jour
l'arborescence des sources locale ; cela met seulement à jour le lien
symbolique de @file{~/.config/guix/current} (@pxref{Invoquer guix pull}).
Lancez @command{git pull} à la place si vous voulez mettre à jour votre
arborescence des source locale.


@node La configuration parfaite
@section La configuration parfaite

The Perfect Setup to hack on Guix is basically the perfect setup used for
Guile hacking (@pxref{Using Guile in Emacs,,, guile, Guile Reference
Manual}).  First, you need more than an editor, you need
@url{http://www.gnu.org/software/emacs, Emacs}, empowered by the wonderful
@url{http://nongnu.org/geiser/, Geiser}.  To set that up, run:

@example
guix package -i emacs guile emacs-geiser
@end example

Geiser permet le développement interactif et incrémental depuis Emacs : la
compilation du code et son évaluation depuis les buffers, l'accès à la
documentation en ligne (docstrings), la complétion sensible au contexte,
@kbd{M-.} pour sauter à la définition d'un objet, un REPL pour tester votre
code, et bien plus (@pxref{Introduction,,, geiser, Geiser User Manual}).
Pour travailler confortablement sur Guix, assurez-vous de modifier le chemin
de chargement de Guile pour qu'il trouve les fichiers source de votre dépôt
:

@lisp
;; @r{Si l'extrait est dans ~/src/guix.}
(with-eval-after-load 'geiser-guile
  (add-to-list 'geiser-guile-load-path "~/src/guix"))
@end lisp

Pour effectivement éditer le code, Emacs a déjà un très bon mode Scheme.
Mais en plus de ça, vous ne devez pas rater
@url{http://www.emacswiki.org/emacs/ParEdit, Paredit}.  Il fournit des
fonctionnalités pour opérer directement sur l'arbre de syntaxe, comme
relever une s-expression ou l'envelopper, absorber ou rejeter la
s-expression suivante, etc.

@cindex extraits de code
@cindex modèles
@cindex réduire la quantité de code commun
Nous fournissons aussi des modèles pour les messages de commit git communs
et les définitions de paquets dans le répertoire @file{etc/snippets}.  Ces
modèles s'utilisent avec @url{http://joaotavora.github.io/yasnippet/,
YASnippet} pour développer des chaînes courtes de déclenchement en extraits
de texte interactifs.  Vous pouvez ajouter le répertoire des modèles dans la
variables @var{yas-snippet-dirs} d'Emacs.

@lisp
;; @r{Si l'extrait est dans ~/src/guix.}
(with-eval-after-load 'yasnippet
  (add-to-list 'yas-snippet-dirs "~/src/guix/etc/snippets"))
@end lisp

Les extraits de messages de commit dépendent de @url{https://magit.vc/,
Magit} pour afficher les fichiers sélectionnés.  Lors de la modification
d'un message de commit, tapez @code{add} suivi de @kbd{TAB} pour insérer un
modèle de message de commit pour ajouter un paquet ; tapez @code{update}
suivi de @kbd{TAB} pour insérer un modèle pour la mise à jour d'un paquet ;
tapez @code{https} suivi de @kbd{TAB} pour insérer un modèle pour le
changement à HTTPS de l'URI de la page d'accueil.

L'extrait principal pour @code{scheme-mode} est lancé en tapant
@code{package…} suivi par @kbd{TAB}.  Cet extrait insère aussi la chaîne de
déclenchement @code{origin…}, qui peut aussi être étendue.  L'extrait
@code{origin} lui-même peut aussi insérer des chaînes de déclenchement qui
finissent sur @code{…}, qui peuvent aussi être étendues.


@node Consignes d'empaquetage
@section Consignes d'empaquetage

@cindex paquets, création
The GNU distribution is nascent and may well lack some of your favorite
packages.  This section describes how you can help make the distribution
grow.

Les paquets de logiciels libres sont habituellement distribués sous forme
@dfn{d'archives de sources} — typiquement des fichiers @file{.tar.gz}
contenant tous les fichiers sources.  Ajouter un paquet à la distribution
signifie essentiellement deux choses : ajouter une @dfn{recette} qui décrit
comment construire le paquet, avec une liste d'autres paquets requis pour le
construire, et ajouter des @dfn{métadonnées de paquet} avec la recette,
comme une description et une licence.

Dans Guix, toutes ces informations sont incorporées dans les
@dfn{définitions de paquets}.  Les définitions de paquets fournissent une
vue de haut-niveau du paquet.  Elles sont écrites avec la syntaxe du langage
de programmation Scheme ; en fait, pour chaque paquet nous définissons une
variable liée à la définition et exportons cette variable à partir d'un
module (@pxref{Modules de paquets}).  Cependant, il n'est @emph{pas} nécessaire
d'avoir une connaissance approfondie du Scheme pour créer des paquets.  Pour
plus d'informations sur les définitions des paquets, @pxref{Définition des paquets}.

Une fois une définition de paquet en place, stocké dans un fichier de
l'arborescence des sources de Guix, il peut être testé avec la commande
@command{guix build} (@pxref{Invoquer guix build}).  Par exemple, en
supposant que le nouveau paquet s'appelle @code{gnew}, vous pouvez lancer
cette commande depuis l'arborescence de construction de Guix (@pxref{Lancer Guix avant qu'il ne soit installé}) :

@example
./pre-inst-env guix build gnew --keep-failed
@end example

Utiliser @code{--keep-failed} rend facile le débogage des échecs car il
fournit l'accès à l'arborescence de construction qui a échouée.  Une autre
sous-commande utile pour le débogage est @code{--log-file}, pour accéder au
journal de construction.

Si le paquet n'est pas connu de la commande @command{guix}, il se peut que
le fichier source ait une erreur de syntaxe, ou qu'il manque une clause
@code{define-public} pour exporter la variable du paquet.  Pour comprendre
cela, vous pouvez charger le module depuis Guile pour avoir plus
d'informations sur la véritable erreur :

@example
./pre-inst-env guile -c '(use-modules (gnu packages gnew))'
@end example

Once your package builds correctly, please send us a patch
(@pxref{Envoyer des correctifs}).  Well, if you need help, we will be happy to
help you too.  Once the patch is committed in the Guix repository, the new
package automatically gets built on the supported platforms by
@url{http://hydra.gnu.org/jobset/gnu/master, our continuous integration
system}.

@cindex substitution
Users can obtain the new package definition simply by running @command{guix
pull} (@pxref{Invoquer guix pull}).  When @code{@value{SUBSTITUTE-SERVER}}
is done building the package, installing the package automatically downloads
binaries from there (@pxref{Substituts}).  The only place where human
intervention is needed is to review and apply the patch.


@menu
* Liberté logiciel::        Ce que la distribution peut contenir.
* Conventions de nommage::   Qu'est-ce qu'un bon nom ?
* Numéros de version::      Lorsque le nom n'est pas suffisant.
* Synopsis et descriptions::  Aider les utilisateurs à trouver le bon 
                                paquet.
* Modules python::           Un peu de comédie anglaise.
* Modules perl::             Petites perles.
* Paquets java::             Pause café.
* Polices de caractères::   À fond les fontes.
@end menu

@node Liberté logiciel
@subsection Liberté logiciel

@c ===========================================================================
@c
@c This file was generated with po4a. Translate the source file.
@c
@c ===========================================================================
@c Adapted from http://www.gnu.org/philosophy/philosophy.html.
@cindex logiciel libre
Le système d'exploitation GNU a été développé pour que les utilisateurs
puissent utiliser leur ordinateur en toute liberté.  GNU est un
@dfn{logiciel libre}, ce qui signifie que les utilisateur ont les
@url{http://www.gnu.org/philosophy/free-sw.fr.html,quatre libertés
essentielles} : exécuter le programmer, étudier et modifier le programme
sous sa forme source, redistribuer des copies exactes et distribuer les
versions modifiées.  Les paquets qui se trouvent dans la distribution GNU ne
fournissent que des logiciels qui respectent ces quatre libertés.

En plus, la distribution GNU suit les
@url{http://www.gnu.org/distros/free-system-distribution-guidelines.html,recommandations
pour les distributions systèmes libres}.  Entre autres choses, ces
recommandations rejettent les microgiciels non libres, les recommandations
de logiciels non libres et discute des façon de gérer les marques et les
brevets.

Certaines sources amont autrement parfaitement libres contiennent une petite
partie facultative qui viole les recommandations ci-dessus, par exemple car
cette partie est du code non-libre.  Lorsque cela arrive, les éléments en
question sont supprimés avec des correctifs ou des bouts de codes appropriés
dans la forme @code{origin} du paquet (@pxref{Définition des paquets}).  De cette
manière, @code{guix build --source} renvoie la source « libérée » plutôt que
la source amont sans modification.


@node Conventions de nommage
@subsection Conventions de nommage

@cindex nom du paquet
Un paquet a en fait deux noms qui lui sont associés : d'abord il y a le nom
de la @emph{variable Scheme}, celui qui suit @code{define-public}.  Par ce
nom, le paquet peut se faire connaître par le code Scheme, par exemple comme
entrée d'un autre paquet.  Deuxièmement, il y a la chaîne dans le champ
@code{name} d'une définition de paquet.  Ce nom est utilisé par les
commandes de gestion des paquets comme @command{guix package} et
@command{guix build}.

Les deux sont habituellement les mêmes et correspondent à la conversion en
minuscule du nom du projet choisi en amont, où les underscores sont
remplacés par des tirets.  Par exemple, GNUnet est disponible en tant que
@code{gnunet} et SDL_net en tant que @code{sdl-net}.

Nous n'ajoutons pas de préfixe @code{lib} au bibliothèques de paquets, à
moins qu'il ne fasse partie du nom officiel du projet.  Mais @pxref{Modules python} et @ref{Modules perl}  pour des règles spéciales concernant les
modules pour les langages Python et Perl.

Les noms de paquets de polices sont gérés différemment, @pxref{Polices de caractères}.


@node Numéros de version
@subsection Numéros de version

@cindex version du paquet
Nous n'incluons en général que la dernière version d'un projet de logiciel
libre donné.  Mais parfois, par exemple pour des versions incompatibles de
bibliothèques, deux (ou plus) versions du même paquet sont requises.  Elles
ont besoin d'un nom de variable Scheme différent.  Nous utilisons le nom
défini dans @ref{Conventions de nommage} pour la version la plus récente ; les
versions précédentes utilisent le même nom, suffixé par @code{-} et le plus
petit préfixe du numéro de version qui permet de distinguer deux versions.

Le nom dans la définition du paquet est le même pour toutes les versions
d'un paquet et ne contient pas de numéro de version.

Par exemple, les version 2.24.20 et 3.9.12 de GTK+ peuvent être inclus de
cette manière :

@example
(define-public gtk+
  (package
    (name "gtk+")
    (version "3.9.12")
    ...))
(define-public gtk+-2
  (package
    (name "gtk+")
    (version "2.24.20")
    ...))
@end example
Si nous voulons aussi GTK+ 3.8.2, cela serait inclus de cette manière :
@example
(define-public gtk+-3.8
  (package
    (name "gtk+")
    (version "3.8.2")
    ...))
@end example

@c See <https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00425.html>,
@c for a discussion of what follows.
@cindex numéro de version, pour les instantanés des systèmes de contrôle de version
Parfois, nous incluons des paquets provenant d'instantanés de systèmes de
contrôle de version (VCS) au lieu de versions publiées formellement.  Cela
devrait rester exceptionnel, car c'est le rôle des développeurs amont de
spécifier quel est la version stable.  Cependant, c'est parfois nécessaire.
Donc, que faut-il mettre dans le champ @code{version} ?

Clairement, nous devons rendre l'identifiant de commit de l'instantané du
VCS visible dans la version, mais nous devons aussi nous assurer que la
version augmente de manière monotone pour que @command{guix package
--upgrade} puisse déterminer quelle version est la plus récente.  Comme les
identifiants de commits, notamment avec Git, n'augmentent pas, nous ajoutons
un numéro de révision qui nous augmentons à chaque fois que nous mettons à
jour vers un nouvel instantané.  La chaîne qui en résulte ressemble à cela :

@example
2.0.11-3.cabba9e
  ^    ^    ^
  |    |    `-- ID du commit en amont
  |    |
  |    `--- révision du paquet Guix
  |
dernière version en amont
@end example

C'est une bonne idée de tronquer les identifiants dans le champ
@code{version} à disons 7 caractères.  Cela évite un problème esthétique (en
supposant que l'esthétique ait un rôle à jouer ici) et des problèmes avec
les limites de l'OS comme la longueur maximale d'un shebang (127 octets pour
le noyau Linux).  Il vaut mieux utilise l'identifiant de commit complet dans
@code{origin} cependant, pour éviter les ambiguïtés.  Une définition de
paquet peut ressembler à ceci :

@example
(define my-package
  (let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7")
        (revision "1"))          ;révision du paquet Guix
    (package
      (version (git-version "0.9" revision commit))
      (source (origin
                (method git-fetch)
                (uri (git-reference
                      (url "git://example.org/my-package.git")
                      (commit commit)))
                (sha256 (base32 "1mbikn@dots{}"))
                (file-name (git-file-name name version))))
      ;; @dots{}
      )))
@end example

@node Synopsis et descriptions
@subsection Synopsis et descriptions

@cindex description du paquet
@cindex résumé du paquet
Comme nous l'avons vu avant, chaque paquet dans GNU@tie{}Guix contient un
résumé et une description (@pxref{Définition des paquets}).  Les résumés et les
descriptions sont importants : ce sont eux que recherche @command{guix
package --search}, et c'est une source d'informations cruciale pour aider
les utilisateurs à déterminer si un paquet donner correspond à leurs
besoins.  En conséquence, les mainteneurs doivent prêter attention à leur
contenu.

Les résumés doivent commencer par une lettre capitale et ne doit pas finir
par un point.  Ils ne doivent pas commencer par « a » ou « the » (« un » ou
« le/la »), ce qui n'apporte généralement rien ; par exemple, préférez «
File-frobbing tool » (« Outil de frobage de fichier ») à « A tool that frobs
file » (« Un outil qui frobe les fichiers »).  Le résumé devrait dire ce que
le paquet est — p.@: ex.@: « Utilitaire du cœur de GNU (fichier, text,
shell) » — ou ce à quoi il sert — p.@: ex.@: le résumé de grep est « Affiche
des lignes correspondant à un motif ».

Gardez à l'esprit que le résumé doit avoir un sens pour une large audience.
Par exemple « Manipulation d'alignements au format SAM » peut avoir du sens
pour un bioinformaticien chevronné, mais n'aidera pas ou pourra perdre une
audience de non-spécialistes.  C'est une bonne idée de créer un résumé qui
donne une idée du domaine d'application du paquet.  Dans cet exemple, cela
donnerait « Manipulation d'alignements de séquences de nucléotides », ce qui
devrait donner une meilleure idée à l'utilisateur pour savoir si c'est ce
qu'il recherche.

Les descriptions devraient faire entre cinq et dix lignes.  Utilisez des
phrases complètes, et évitez d'utiliser des acronymes sans les introduire
d'abord.  Évitez les phrases marketings comme « world-leading », «
industrial-strength » et « next-generation » et évitez les superlatifs comme
« the most advanced » — ils ne sont pas utiles pour les utilisateurs qui
cherchent un paquet et semblent même un peu suspects.  À la place, essayez
d'être factuels, en mentionnant les cas d'utilisation et les
fonctionnalités.

@cindex balisage texinfo, dans les descriptions de paquets
Les descriptions peuvent inclure du balisage Texinfo, ce qui est utile pour
introduire des ornements comme @code{@@code} ou @code{@@dfn}, des listes à
points ou des hyperliens (@pxref{Overview,,, texinfo, GNU Texinfo}).
Cependant soyez prudents lorsque vous utilisez certains symboles, par
exemple @samp{@@} et les accolades qui sont les caractères spéciaux de base
en Texinfo (@pxref{Special Characters,,, texinfo, GNU Texinfo}).  Les
interfaces utilisateurs comme @command{guix package --show} prennent en
charge le rendu.

Les résumés et les descriptions sont traduits par des volontaires
@uref{http://translationproject.org/domain/guix-packages.html, sur le projet
de traduction} pour que le plus d'utilisateurs possible puissent les lire
dans leur langue natale.  Les interfaces utilisateurs les recherchent et les
affichent dans la langue spécifiée par le paramètre de régionalisation
actuel.

Pour permettre à @command{xgettext} de les extraire comme des chaînes
traduisibles, les résumés et les descriptions @emph{doivent être des chaînes
litérales}.  Cela signifie que vous ne pouvez pas utiliser
@code{string-append} ou @code{format} pour construire ces chaînes :

@lisp
(package
  ;; @dots{}
  (synopsis "Ceci est traduisible")
  (description (string-append "Ceci n'est " "*pas*" " traduisible.")))
@end lisp

La traduction demande beaucoup de travail, donc en tant que packageur,
faîtes encore plus attention à vos résumés et descriptions car chaque
changement peut demander d'autant plus de travail de la part des
traducteurs.  Pour les aider, il est possible de donner des recommandations
ou des instructions qu'ils pourront voir en insérant des commentaires
spéciaux comme ceci (@pxref{xgettext Invocation,,, gettext, GNU Gettext}) :

@example
;; TRANSLATORS: "X11 resize-and-rotate" should not be translated.
(description "ARandR is designed to provide a simple visual front end
for the X11 resize-and-rotate (RandR) extension. @dots{}")
@end example


@node Modules python
@subsection Modules python

@cindex python
Nous incluons actuellement Python 2 et Python 3, sous les noms de variables
Scheme @code{python-2} et @code{python} comme expliqué dans @ref{Numéros de version}.  Pour éviter la confusion et les problèmes de noms avec d'autres
langages de programmation, il semble désirable que le nom d'un paquet pour
un module Python contienne le mot @code{python}.

Certains modules ne sont compatibles qu'avec une version de Python, d'autres
avec les deux.  Si le paquet Foo ne compile qu'avec Ptyhon 3, on le nomme
@code{python-foo} ; s'il ne compile qu'avec Python 2, on le nome
@code{python2-foo}.  S'il est compatible avec les deux versions, nous créons
deux paquets avec les noms correspondant.

If a project already contains the word @code{python}, we drop this; for
instance, the module python-dateutil is packaged under the names
@code{python-dateutil} and @code{python2-dateutil}.  If the project name
starts with @code{py} (e.g.@: @code{pytz}), we keep it and prefix it as
described above.

@subsubsection Spécifier les dépendances
@cindex entrées, pour les paquets Python

Les informations de dépendances pour les paquets Python se trouvent
généralement dans l'arborescence des source du paquet, avec plus ou moins de
précision : dans le fichier @file{setup.py}, dans @file{requirements.txt} ou
dans @file{tox.ini}.

Votre mission, lorsque vous écrivez une recette pour un paquet Python, est
de faire correspondre ces dépendances au bon type « d'entrée »
(@pxref{Référence de paquet, inputs}).  Bien que l'importeur @code{pypi} fasse
du bon boulot (@pxref{Invoquer guix import}), vous devriez vérifier la liste
suivant pour déterminer où va telle dépendance.

@itemize

@item
Nous empaquetons Python 2 avec @code{setuptools} et @code{pip} installé
comme Python 3.4 par défaut.  Ainsi, vous n'avez pas à spécifié ces
entrées.  @command{guix lint} vous avertira si vous faîtes cela.

@item
Les dépendances Python requises à l'exécutions vont dans
@code{propagated-inputs}.  Elles sont typiquement définies dans le mot-clef
@code{install_requires} dans @file{setup.py} ou dans le fichier
@file{requirements.txt}.

@item
Les paquets Python requis uniquement à la construction — p.@: ex.@: ceux
listés dans le mot-clef @code{setup_requires} de @file{setup.py} — ou
seulement pour les tests — p.@: ex.@: ceux dans @code{tests_require} — vont
dans @code{native-inputs}.  La raison est qu'ils n'ont pas besoin d'être
propagés car ils ne sont pas requis à l'exécution et dans le cas d'une
compilation croisée, c'est l'entrée « native » qu'il nous faut.

Les cadriciels de tests @code{pytest}, @code{mock} et @code{nose} sont des
exemples.  Bien sûr si l'un de ces paquets est aussi requis à l'exécution,
il doit aller dans @code{propagated-inputs}.

@item
Tout ce qui ne tombe pas dans les catégories précédentes va dans
@code{inputs}, par exemple des programmes pour des bibliothèques C requises
pour construire des paquets Python avec des extensions C.

@item
Si un paquet Python a des dépendances facultatives (@code{extras_require}),
c'est à vous de décider de les ajouter ou non, en fonction du ratio entre
utilité et complexité (@pxref{Envoyer des correctifs, @command{guix size}}).

@end itemize


@node Modules perl
@subsection Modules perl

@cindex perl
Les programmes Perl utiles en soit sont nommés comme les autres paquets,
avec le nom amont en minuscule.  Pour les paquets Perl contenant une seule
classe, nous utilisons le nom de la classe en minuscule, en remplaçant les
occurrences de @code{::} par des tirets et en préfixant le tout par
@code{perl-}.  Donc la classe @code{XML::Parser} devient
@code{perl-xml-parser}.  Les modules contenant plusieurs classes gardent
leur nom amont en minuscule et sont aussi préfixés par @code{perl-}.  Ces
modules tendent à avoir le mot @code{perl} quelque part dans leur nom, que
nous supprimons en faveur du préfixe.  Par exemple, @code{libwww-perl}
devient @code{perl-libwww}.


@node Paquets java
@subsection Paquets java

@cindex java
Le programmes Java utiles en soit sont nommés comme les autres paquets, avec
le nom amont en minuscule.

Pour éviter les confusions et les problèmes de nom avec d'autres langages de
programmation, il est désirable que le nom d'un paquet Java soit préfixé par
@code{java-}.  Si un projet contient déjà le mot @code{java}, nous le
supprimons, par exemple le paquet @code{ngsjava} est empaqueté sous le nom
@code{java-ngs}.

Pour les paquets java contenant une seul classe ou une petite hiérarchie de
classes, nous utilisons le nom de la classe en minuscule, en remplaçant les
occurrences de @code{.} par des tirets et en préfixant le tout par
@code{java-}.  Donc la classe @code{apache.commons.cli} devient
@code{java-apache-commons-cli}.


@node Polices de caractères
@subsection Polices de caractères

@cindex polices
Pour les polices qui n esont en général par installées par un utilisateurs
pour du traitement de texte, ou qui sont distribuées en tant que partie d'un
paquet logiciel plus gros, nous nous appuyons sur les règles générales pour
les logiciels ; par exemple, cela s'applique aux polices livrées avec le
système X.Org ou les polices qui font partie de TeX Live.

Pour rendre plus facile la recherche par l'utilisateur, les noms des autres
paquets contenant seulement des polices sont construits ainsi,
indépendamment du nom du paquet en amont.

Le nom d'un paquet contenant une unique famille de polices commence par
@code{font-} ; il est suivi du nom du fondeur et d'un tiret @code{-} si le
fondeur est connu, et du nom de la police, dont les espaces sont remplacés
par des tirets (et comme d'habitude, toutes les lettres majuscules sont
transformées en minuscules).  Par exemple, la famille de polices Gentium de
SIL est empaqueté sous le nom @code{font-sil-gentium}.

Pour un paquet contenant plusieurs familles de polices, le nom de la
collection est utilisée à la place du nom de la famille.  Par exemple les
polices Liberation consistent en trois familles, Liberation Sans, Liberation
Serif et Liberation Mono.  Elles pourraient être empaquetées séparément sous
les noms @code{font-liberation-sans} etc, mais comme elles sont distribuées
ensemble sous un nom commun, nous préférons les empaqueter ensemble en tant
que @code{font-liberation}.

Dans le cas où plusieurs formats de la même famille ou collection sont
empaquetés séparément, une forme courte du format, préfixé d'un tiret est
ajouté au nom du paquet.  Nous utilisont @code{-ttf} pour les polices
TrueType, @code{-otf} pour les polices OpenType et @code{-type1} pour les
polices Type 1 de PostScript.


@node Style de code
@section Style de code

En général notre code suit le Standard de Code GNU (@pxref{Top,,, standards,
GNU Coding Standards}).  Cependant, il ne parle pas beaucoup de Scheme, donc
voici quelques règles supplémentaires.

@menu
* Paradigme de programmation::  Comment composer vos éléments.
* Modules::                  Où stocker votre code ?
* Types de données et reconnaissance de motif::  Implémenter des 
                                                    structures de données.
* Formatage du code::        Conventions d'écriture.
@end menu

@node Paradigme de programmation
@subsection Paradigme de programmation

Le code Scheme dans Guix est écrit dans un style purement fonctionnel.  Le
code qui s'occupe des entrées-sorties est une exception ainsi que les
procédures qui implémentent des concepts bas-niveau comme la procédure
@code{memoize}.

@node Modules
@subsection Modules

Les modules Guile qui sont sensés être utilisés du côté de la construction
doivent se trouver dans l'espace de nom @code{(guix build @dots{})}.  Ils ne
doivent pas se référer à d'autres modules Guix ou GNU@.  Cependant il est
correct pour un module « côté hôte » de dépendre d'un module coté
construction.

Les modules qui s'occupent du système GNU général devraient se trouver dans
l'espace de nom @code{(gnu @dots{})} plutôt que @code{(guix @dots{})}.

@node Types de données et reconnaissance de motif
@subsection Types de données et reconnaissance de motif

La tendance en Lisp classique est d'utiliser des listes pour tout
représenter et de naviguer dedans « à la main ( avec @code{car}, @code{cdr},
@code{cadr} et compagnie.  Il y a plusieurs problèmes avec ce style,
notamment le fait qu'il soit dur à lire, source d'erreur et un obstacle aux
rapports d'erreur bien typés.

Le code de Guix devrait définir des types de données appropriées (par
exemple, avec @code{define-record-type*}) plutôt que d'abuser des listes.
En plus, il devrait utiliser la recherche de motifs, via le module Guile
@code{(ice-9 match)}, surtout pour rechercher dans des listes.

@node Formatage du code
@subsection Formatage du code

@cindex formater le code
@cindex style de code
Lorsque nous écrivons du code Scheme, nous suivons la sagesse commune aux
programmeurs Scheme.  En général, nous suivons les
@url{http://mumble.net/~campbell/scheme/style.txt, règles de style de
Riastradh}.  Ce document décrit aussi les conventions utilisées dans le code
de Guile.  Il est bien pensé et bien écrit, alors n'hésitez pas à le lire.

Certaines formes spéciales introduites dans Guix comme la macro
@code{substitute*} ont des règles d'indentation spécifiques.  Elles sont
définies dans le fichier @file{.dir-locals.el} qu'Emacs utilise
automatiquement.  Remarquez aussi qu'Emacs-Guix fournit le mode
@code{guix-devel-mode} qui indente et colore le code Guix correctement
(@pxref{Development,,, emacs-guix, The Emacs-Guix Reference Manual}).

@cindex indentation, du code
@cindex formatage, du code
Si vous n'utilisez pas Emacs, assurez-vous que votre éditeur connaisse ces
règles.  Pour indenter automatiquement une définition de paquet, vous pouvez
aussi lancer :

@example
./etc/indent-code.el gnu/packages/@var{file}.scm @var{package}
@end example

@noindent
Cela indente automatiquement la définition de @var{package} dans
@file{gnu/packages/@var{file}.scm} en lançant Emacs en mode commande.  Pour
indenter un fichier complet, n'indiquez pas de second argument :

@example
./etc/indent-code.el gnu/services/@var{file}.scm
@end example

@cindex Vim, édition de code Scheme
Si vous éditez du code avec Vim, nous recommandons de lancer @code{:set
autoindent} pour que votre code soit automatiquement indenté au moment où
vous l'entrez.  En plus,
@uref{https://www.vim.org/scripts/script.php?script_id=3998,
@code{paredit.vim}} peut vous aider à gérer toutes ces parenthèses.

Nous demandons que toutes les procédure de premier niveau contiennent une
chaîne de documentation.  Ce prérequis peut être relâché pour les procédures
privées simples dans l'espace de nom @code{(guix build @dots{})} cependant.

Les procédures ne devraient pas avoir plus de quatre paramètres
positionnés. Utilisez des paramètres par mot-clefs pour les procédures qui
prennent plus de quatre paramètres.


@node Envoyer des correctifs
@section Envoyer des correctifs

Le développement se fait avec le système de contrôle de version Git.  Ainsi,
l'accès au dépôt n'est pas strictement nécessaire.  Nous accueillons les
contributions sous forme de correctifs produits par @code{git format-patch}
envoyés sur la liste de diffusion @email{guix-patches@@gnu.org}.

Cette liste de diffusion est gérée par une instance Debbugs accessible à
l'adresse @uref{https://bugs.gnu.org/guix-patches}, qui nous permet de
suivre les soumissions.  Chaque message envoyé à cette liste se voit
attribuer un numéro de suivi ; les gens peuvent ensuite répondre à cette
soumission en envoyant un courriel à @code{@var{NNN}@@debbugs.gnu.org}, où
@var{NNN} est le numéro de suivi (@pxref{Envoyer une série de correctifs}).

Veuillez écrire les messages de commit dans le format ChangeLog
(@pxref{Change Logs,,, standards, GNU Coding Standards}) ; vous pouvez
regarder l'historique des commits pour trouver des exemples.

Avant de soumettre un correctif qui ajoute ou modifie la définition d'un
paquet, veuillez vérifier cette check-list :

@enumerate
@item
Si les auteurs du paquet logiciel fournissent une signature cryptographique
pour l'archive, faîtes un effort pour vérifier l'authenticité de l'archive.
Pour un fichier de signature GPG détaché, cela se fait avec la commande
@code{gpg --verify}.

@item
Prenez un peu de temps pour fournir un synopsis et une description adéquats
pour le paquet.  Voir @xref{Synopsis et descriptions} pour quelques lignes
directrices.

@item
Lancez @code{guix lint @var{paquet}}, où @var{paquet} est le nom du nouveau
paquet ou du paquet modifié, et corrigez les erreurs qu'il rapporte
(@pxref{Invoquer guix lint}).

@item
Assurez-vous que le paquet se construise sur votre plate-forme avec
@code{guix build @var{paquet}}.

@item
We recommend you also try building the package on other supported
platforms.  As you may not have access to actual hardware platforms, we
recommend using the @code{qemu-binfmt-service-type} to emulate them.  In
order to enable it, add the following service to the list of services in
your @code{operating-system} configuration:

@example
(service qemu-binfmt-service-type
 (qemu-binfmt-configuration
   (platforms (lookup-qemu-platforms "arm" "aarch64" "ppc" "mips64el"))
   (guix-support? #t)))
@end example

Then reconfigure your system.

You can then build packages for different platforms by specifying the
@code{--system} option.  For example, to build the "hello" package for the
armhf, aarch64, powerpc, or mips64 architectures, you would run the
following commands, respectively:
@example
guix build --system=armhf-linux --rounds=2 hello
guix build --system=aarch64-linux --rounds=2 hello
guix build --system=powerpc-linux --rounds=2 hello
guix build --system=mips64el-linux --rounds=2 hello
@end example

@item
@cindex construction groupée
Assurez-vous que le paquet n'utilise pas de copie groupée d'un logiciel déjà
disponible dans un paquet séparé.

Parfois, les paquets incluent des copie du code source de leurs dépendances
pour le confort de leurs utilisateurs.  Cependant, en tant que distribution,
nous voulons nous assurer que ces paquets utilisent bien les copient que
nous avons déjà dans la distribution si elles existent.  Cela améliore
l'utilisation des ressources (la dépendance n'est construite et stockée
qu'une seule fois) et permet à la distribution de faire des changements
transversaux comme appliquer des correctifs de sécurité pour un paquet donné
depuis un unique emplacement et qu'ils affectent tout le système, ce
qu'empêchent les copies groupées.

@item
Take a look at the profile reported by @command{guix size} (@pxref{Invoquer guix size}).  This will allow you to notice references to other packages
unwillingly retained.  It may also help determine whether to split the
package (@pxref{Des paquets avec plusieurs résultats}), and which optional
dependencies should be used.  In particular, avoid adding @code{texlive} as
a dependency: because of its extreme size, use @code{texlive-tiny} or
@code{texlive-union} instead.

@item
Pour les changements important, vérifiez que les paquets qui en dépendent
(s'ils existent) ne sont pas affectés par le changement ; @code{guix refresh
--list-dependant @var{paquet}} vous aidera (@pxref{Invoquer guix refresh}).

@c See <https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html>.
@cindex stratégie de branche
@cindex stratégie de planification des reconstructions
Suivant le nombre de paquets dépendants et donc le nombre de reconstruction
induites, les commits vont vers des branches différentes, suivant ces
principes :

@table @asis
@item 300 paquets dépendants ou moins
branche @code{master} (changements non-disruptifs).

@item entre 300 et 1 200 paquets dépendants
branche @code{staging} (changements non-disruptifs).  Cette branche devrait
être fusionnées dans @code{master} tous les 3 semaines.  Les changements par
thèmes (par exemple une mise à jour de la pile GNOME) peuvent aller dans une
branche spécifique (disons, @code{gnome-updates}).

@item plus de 1 200 paquets dépendants
branche @code{core-updates} (peut inclure des changements majeurs et
potentiellement disruptifs).  Cette branche devrait être fusionnée dans
@code{master} tous les 2,5 mois environ.
@end table

Toutes ces branches sont @uref{https://hydra.gnu.org/project/gnu, gérées par
notre ferme de construction} et fusionnées dans @code{master} une fois que
tout a été construit correctement.  Cela nous permet de corriger des
problèmes avant qu'ils n'atteignent les utilisateurs et réduit la fenêtre
pendant laquelle les binaires pré-construits ne sont pas disponibles.

@c TODO: It would be good with badges on the website that tracks these
@c branches.  Or maybe even a status page.
Généralement les autres branches que @code{master} sont considérées comme
@emph{gelées} s'il y a eu une évaluation récente ou qu'il y a une branche
@code{-next} correspondante.  Demandez sur la liste de diffusion ou sur IRC
si vous n'êtes pas sûr de savoir où pousser votre correctif.

@item
@cindex déterminisme, du processus de construction
@cindex construction reproductibles, vérification
Vérifiez si le processus de construction du paquet est déterministe.  Cela
signifie typiquement vérifier qu'une construction indépendante du paquet
renvoie exactement le même résultat que vous avez obtenu, bit à bit.

Une manière simple de le faire est de reconstruire le paquet plusieurs fois
à la suite sur votre machine (@pxref{Invoquer guix build}) :

@example
guix build --rounds=2 mon-paquet
@end example

Cela est suffisant pour trouver une classe de non-déterminisme commune,
comme l'horodatage ou des sorties générées aléatoirement dans le résultat de
la construction.

Another option is to use @command{guix challenge} (@pxref{Invoquer guix challenge}).  You may run it once the package has been committed and built
by @code{@value{SUBSTITUTE-SERVER}} to check whether it obtains the same
result as you did.  Better yet: Find another machine that can build it and
run @command{guix publish}.  Since the remote build machine is likely
different from yours, this can catch non-determinism issues related to the
hardware---e.g., use of different instruction set extensions---or to the
operating system kernel---e.g., reliance on @code{uname} or @file{/proc}
files.

@item
Lorsque vous écrivez de la documentation, utilisez une formulation au genre
neutre lorsque vous vous référez à des personnes, comme le
@uref{https://fr.wikipedia.org/wiki/They_singulier, ``they''@comma{}
``their''@comma{} ``them'' singulier} (en anglais).

@item
Vérifiez que votre correctif contienne seulement un ensemble de changements
liés.  Grouper des changements non liés ensemble rend la revue plus
difficile et plus lente.

Ajouter plusieurs paquet ou une mise à jour d'un paquet avec des corrections
dans ce paquet sont des exemples de changements sans rapport.

@item
Suivez nos règles de formatage de code, éventuellement en lançant le script
@command{et/indent-code.el} pour le faire automatiquement (@pxref{Formatage
du code}).

@item
Si possible, utilisez des miroirs dans l'URL des sources (@pxref{Invoquer guix download}).  Utilisez des URL stable, pas des URL générées.  Par
exemple, les archives GitHub ne sont pas nécessairement identiques d'une
génération à la suivante, donc il vaut mieux dans ce cas cloner le dépôt.
N'utilisez pas le champ @command{name} dans l'URL : ce n'est pas très utile
et si le nom change, l'URL sera probablement erronée.

@end enumerate

Lorsque vous envoyez un correctif à la liste de diffusion, utilisez
@samp{[PATCH] @dots{}} comme sujet.  Vous pouvez utiliser votre client de
courriel ou la commande @command{git send-email} (@pxref{Envoyer une série
de correctifs}).  Nous préférons recevoir des correctifs en texte brut, soit
en ligne, soit en pièce-jointe MIME@.   Nous vous conseillons de faire
attention si votre client de courriel change par exemple les retours à la
ligne ou l'indentation, ce qui peut casser les correctifs.

Lorsqu'un bogue est résolu, veuillez fermer le fil en envoyant un courriel à
@email{@var{NNN}-done@@debbugs.gnu.org}.

@unnumberedsubsec Envoyer une série de correctifs
@anchor{Envoyer une série de correctifs}
@cindex série de correctifs
@cindex @code{git send-email}
@cindex @code{git-send-email}

@c Debbugs bug: https://debbugs.gnu.org/db/15/15361.html
Lorsque vous envoyez une série de correctifs (p.@@:: ex.@: avec @code{git
send-email}), envoyez d'abord une premier message à
@email{guix-patches@@gnu.org} puis envoyez le reste des correctifs à
@email{@var{NNN}@@debbugs.gnu.org} pour vous assurer qu'ils seront groupés
ensemble.  Voyez @uref{https://debbugs.gnu.org/Advanced.html, la
documentation de Debbugs} pour plus d'informations.