Contribuer
**********

Ce projet est un effort coopératif et nous avons besoin de votre aide pour le faire grandir ! Contactez-nous sur guix-devel@gnu.org et #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 (see Consignes d'empaquetage).

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 http://contributor-covenant.org/.  Vous pouvez trouver une version locale dans le fichier 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.

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 :

     git clone https://git.savannah.gnu.org/git/guix.git

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 (see Prérequis).

  * GNU Autoconf (http://gnu.org/software/autoconf/);

  * GNU Automake (http://gnu.org/software/automake/);

  * GNU Gettext (http://gnu.org/software/gettext/);

  * GNU Texinfo (http://gnu.org/software/texinfo/);

  * Graphviz (http://www.graphviz.org/);

  * GNU Help2man (facultatif) (http://www.gnu.org/software/help2man/).

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 :

     guix environment guix

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

     guix environment guix --ad-hoc help2man git strace

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

     configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES

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

     export ACLOCAL_PATH=/usr/share/aclocal

See Macro Search Path (The GNU Automake Manual), pour plus d'information.

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

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

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é make install.  Pour cela, vous devez d'abord avoir un environnement avec toutes les dépendances disponibles (see Construire depuis Git), puis préfixer chaque commande par ./pre-inst-env (le script 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 ./configure) comme cela (L'option -E de sudo garantie que GUILE_LOAD_PATH est bien paramétré pour guix-daemon et pour que les outils qu'il utilise puissent trouver les modules Guile dont ils ont besoin.) :

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

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

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

     ;;; ("x86_64-linux")

... et pour un REPL (see Using Guile Interactively (Guile Reference Manual))

     $ ./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

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

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

La configuration parfaite
=========================

La configuration parfaite pour travailler sur Guix est simplement la configuration parfaite pour travailler en Guile (see Using Guile in Emacs (Guile Reference Manual)).  Tout d'abord, vous avez besoin de mieux qu'un éditeur de texte, vous avez besoin de Emacs (http://www.gnu.org/software/emacs), amélioré par le superbe Geiser (http://nongnu.org/geiser/).  Pour paramétrer cela, lancez :

     guix package -i emacs guile emacs-geiser

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, M-. pour sauter à la définition d'un objet, un REPL pour tester votre code, et bien plus (see Introduction (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 :

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

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 Paredit (http://www.emacswiki.org/emacs/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.

Nous fournissons aussi des modèles pour les messages de commit git communs et les définitions de paquets dans le répertoire etc/snippets.  Ces modèles s'utilisent avec YASnippet (http://joaotavora.github.io/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 YAS-SNIPPET-DIRS d'Emacs.

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

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

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

Consignes d'empaquetage
=======================

La distribution GNU est jeune et vos paquets préférés peuvent manquer. Cette section décrit comment vous pouvez aider à agrandir la distribution.

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

Dans Guix, toutes ces informations sont incorporées dans les 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 (see Modules de paquets).  Cependant, il n'est 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, see 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 guix build (see Invoquer guix build).  Par exemple, en supposant que le nouveau paquet s'appelle gnew, vous pouvez lancer cette commande depuis l'arborescence de construction de Guix (see Lancer Guix avant qu'il ne soit installé) :

     ./pre-inst-env guix build gnew --keep-failed

Utiliser --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 --log-file, pour accéder au journal de construction.

Si le paquet n'est pas connu de la commande guix, il se peut que le fichier source ait une erreur de syntaxe, ou qu'il manque une clause 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 :

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

Une fois que votre paquet est correctement construit, envoyez-nous un correctif (see Contribuer).  Enfin, si vous avez besoin d'aide, nous serrons ravis de vous aider.  Une fois que le correctif soumis est committé dans le dépôt Guix, le nouveau paquet est automatiquement construit sur les plate-formes supportées par notre système d'intégration continue (http://hydra.gnu.org/jobset/gnu/master).

On peut obtenir la nouvelle définition du paquet simplement en lançant guix pull (see Invoquer guix pull). Lorsque SUBSTITUTE-SERVER a fini de construire le paquet, l'installation du paquet y télécharge automatiquement les binaires (see Substituts). La seule intervention humaine requise est pendant la revue et l'application du correctif.

Liberté logiciel
----------------

Le système d'exploitation GNU a été développé pour que les utilisateurs puissent utiliser leur ordinateur en toute liberté.  GNU est un logiciel libre, ce qui signifie que les utilisateur ont les quatre libertés essentielles (http://www.gnu.org/philosophy/free-sw.fr.html) : 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 recommandations pour les distributions systèmes libres (http://www.gnu.org/distros/free-system-distribution-guidelines.html).  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 origin du paquet (see Définition des paquets).  De cette manière, guix build --source renvoie la source « libérée » plutôt que la source amont sans modification.

Conventions de nommage
----------------------

Un paquet a en fait deux noms qui lui sont associés : d'abord il y a le nom de la variable Scheme, celui qui suit 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 name d'une définition de paquet.  Ce nom est utilisé par les commandes de gestion des paquets comme guix package et 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 gnunet et SDL_net en tant que sdl-net.

Nous n'ajoutons pas de préfixe lib au bibliothèques de paquets, à moins qu'il ne fasse partie du nom officiel du projet.  Mais see Modules python et 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, see Polices de caractères.

Numéros de version
------------------

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 Conventions de nommage pour la version la plus récente ; les versions précédentes utilisent le même nom, suffixé par - 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 :

     (define-public gtk+
       (package
         (name "gtk+")
         (version "3.9.12")
         ...))
     (define-public gtk+-2
       (package
         (name "gtk+")
         (version "2.24.20")
         ...))

Si nous voulons aussi GTK+ 3.8.2, cela serait inclus de cette manière :

     (define-public gtk+-3.8
       (package
         (name "gtk+")
         (version "3.8.2")
         ...))

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 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 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 :

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

C'est une bonne idée de tronquer les identifiants dans le champ 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 origin cependant, pour éviter les ambiguïtés.  Une définition de paquet peut ressembler à ceci :

     (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..."))
                     (file-name (git-file-name name version))))
           ;; ...
           )))

Synopsis et descriptions
------------------------

Comme nous l'avons vu avant, chaque paquet dans GNU Guix contient un résumé et une description (see Définition des paquets).  Les résumés et les descriptions sont importants : ce sont eux que recherche 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.

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

Les résumés et les descriptions sont traduits par des volontaires sur le projet de traduction (http://translationproject.org/domain/guix-packages.html) 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 à xgettext de les extraire comme des chaînes traduisibles, les résumés et les descriptions doivent être des chaînes litérales.  Cela signifie que vous ne pouvez pas utiliser string-append ou format pour construire ces chaînes :

     (package
       ;; ...
       (synopsis "Ceci est traduisible")
       (description (string-append "Ceci n'est " "*pas*" " traduisible.")))

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 (see xgettext Invocation (GNU Gettext)) :

     ;; 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. ...")

Modules python
--------------

Nous incluons actuellement Python 2 et Python 3, sous les noms de variables Scheme python-2 et python comme expliqué dans 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 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 python-foo ; s'il ne compile qu'avec Python 2, on le nome python2-foo.  S'il est compatible avec les deux versions, nous créons deux paquets avec les noms correspondant.

Si un projet contient déjà le mot python, on l'enlève, par exemple le module python-dateutil est packagé sous les noms python-dateutil et python2-dateutil.  Si le nom du projet commence par py (p. ex. pytz), on le garde et on le préfixe comme décrit ci-dessus.

Spécifier les dépendances
.........................

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 setup.py, dans requirements.txt ou dans 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 » (see inputs).  Bien que l'importeur pypi fasse du bon boulot (see Invoquer guix import), vous devriez vérifier la liste suivant pour déterminer où va telle dépendance.

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

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

  * Les paquets Python requis uniquement à la construction — p. ex. ceux listés dans le mot-clef setup_requires de setup.py — ou seulement pour les tests — p. ex. ceux dans tests_require — vont dans 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 pytest, mock et nose sont des exemples.  Bien sûr si l'un de ces paquets est aussi requis à l'exécution, il doit aller dans propagated-inputs.

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

  * Si un paquet Python a des dépendances facultatives (extras_require), c'est à vous de décider de les ajouter ou non, en fonction du ratio entre utilité et complexité (see guix size).

Modules 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 :: par des tirets et en préfixant le tout par perl-.  Donc la classe XML::Parser devient perl-xml-parser.  Les modules contenant plusieurs classes gardent leur nom amont en minuscule et sont aussi préfixés par perl-.  Ces modules tendent à avoir le mot perl quelque part dans leur nom, que nous supprimons en faveur du préfixe.  Par exemple, libwww-perl devient perl-libwww.

Paquets 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 java-.  Si un projet contient déjà le mot java, nous le supprimons, par exemple le paquet ngsjava est empaqueté sous le nom 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 . par des tirets et en préfixant le tout par java-.  Donc la classe apache.commons.cli devient java-apache-commons-cli.

Polices de caractères
---------------------

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 font- ; il est suivi du nom du fondeur et d'un tiret - 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 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 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 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 -ttf pour les polices TrueType, -otf pour les polices OpenType et -type1 pour les polices Type 1 de PostScript.

Style de code
=============

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

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 memoize.

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 (guix build ...).  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 (gnu ...) plutôt que (guix ...).

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 car, cdr, 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 define-record-type*) plutôt que d'abuser des listes. En plus, il devrait utiliser la recherche de motifs, via le module Guile (ice-9 match), surtout pour rechercher dans des listes.

Formatage du code
-----------------

Lorsque nous écrivons du code Scheme, nous suivons la sagesse commune aux programmeurs Scheme.  En général, nous suivons les règles de style de Riastradh (http://mumble.net/~campbell/scheme/style.txt).  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 substitute* ont des règles d'indentation spécifiques.  Elles sont définies dans le fichier .dir-locals.el qu'Emacs utilise automatiquement.  Remarquez aussi qu'Emacs-Guix fournit le mode guix-devel-mode qui indente et colore le code Guix correctement (see Développement (The Emacs-Guix Reference Manual)).

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 :

     ./etc/indent-code.el gnu/packages/FILE.scm PACKAGE

Cela indente automatiquement la définition de PACKAGE dans gnu/packages/FILE.scm en lançant Emacs en mode commande.  Pour indenter un fichier complet, n'indiquez pas de second argument :

     ./etc/indent-code.el gnu/services/FILE.scm

Si vous éditez du code avec Vim, nous recommandons de lancer :set autoindent pour que votre code soit automatiquement indenté au moment où vous l'entrez.  En plus, paredit.vim (https://www.vim.org/scripts/script.php?script_id=3998) 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 (guix build ...) 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.

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 git format-patch envoyés sur la liste de diffusion guix-patches@gnu.org.

Cette liste de diffusion est gérée par une instance Debbugs accessible à l'adresse 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 à NNN@debbugs.gnu.org, où NNN est le numéro de suivi (see Envoyer une série de correctifs).

Veuillez écrire les messages de commit dans le format ChangeLog (see Change Logs (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 :

 1. 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 gpg --verify.

 2. Prenez un peu de temps pour fournir un synopsis et une description adéquats pour le paquet.  Voir Synopsis et descriptions pour quelques lignes directrices.

 3. Lancez guix lint PAQUET, où PAQUET est le nom du nouveau paquet ou du paquet modifié, et corrigez les erreurs qu'il rapporte (see Invoquer guix lint).

 4. Assurez-vous que le paquet se construise sur votre plate-forme avec guix build PAQUET.

 5. Nous vous recommandons aussi d'essayer de construire le paquet sur les autres plate-formes prises en charge.  Comme vous n'avez pas forcément accès aux plate-formes matérielles, nous vous recommandons d'utiliser le qemu-binfmt-service-type pour les émuler.  Pour cela, ajoutez le service suivant à la liste des services dans votre configuration de système d'exploitation :

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

     Puis reconfigurez votre système.

     Vous pourrez ensuite construire les paquets pour différentes plate-formes en spécifiant l'option --system.  Par exemple pour construire le paquet « hello » pour les architectures armhf, aarch64 ou mips64, vous devrez lancer les commandes suivantes, respectivement :

          guix build --system=armhf-linux --rounds=2 hello
          guix build --system=aarch64-linux --rounds=2 hello
          guix build --system=mips64el-linux --rounds=2 hello

 6. 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.

 7. Regardez le profil rapporté par guix size (see Invoquer guix size).  Cela vous permettra de remarquer des références à d'autres paquets qui ont été retenus sans que vous vous y attendiez.  Il peut aussi aider à déterminer s'il faut découper le paquet (see Des paquets avec plusieurs résultats) et quelles dépendances facultatives utiliser.  En particulier, évitez d'ajouter texlive en dépendance : à cause de sa taille extrême, utilisez texlive-tiny ou texlive-union à la place.

 8. Pour les changements important, vérifiez que les paquets qui en dépendent (s'ils existent) ne sont pas affectés par le changement ; guix refresh --list-dependant PAQUET vous aidera (see Invoquer guix refresh).

     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 :

     300 paquets dépendants ou moins
          branche master (changements non-disruptifs).

     entre 300 et 1 200 paquets dépendants
          branche staging (changements non-disruptifs).  Cette branche devrait être fusionnées dans 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, gnome-updates).

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

     Toutes ces branches sont gérées par notre ferme de construction (https://hydra.gnu.org/project/gnu) et fusionnées dans 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.

     Généralement les autres branches que master sont considérées comme gelées s'il y a eu une évaluation récente ou qu'il y a une branche -next correspondante.  Demandez sur la liste de diffusion ou sur IRC si vous n'êtes pas sûr de savoir où pousser votre correctif.

 9. 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 (see Invoquer guix build) :

          guix build --rounds=2 mon-paquet

     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.

     Une autre option consiste à utiliser guix challenge (see Invoquer guix challenge).  Vous pouvez lancer la commande une fois que les paquets ont été committés et construits par SUBSTITUTE-SERVER pour vérifier s'il obtient le même résultat que vous.  Mieux encore : trouvez une autre machine qui peut le construire et lancez guix publish.  Puisque la machine distante est sûrement différente de la vôtre, cela peut trouver des problèmes de non-déterminisme liés au matériel — par exemple utiliser une extension du jeu d'instruction — ou du noyau du système d'exploitation — par exemple se reposer sur uname ou les fichiers de /proc.

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

 11. 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.

 12. Suivez nos règles de formatage de code, éventuellement en lançant le script et/indent-code.el pour le faire automatiquement (see Formatage du code).

 13. Si possible, utilisez des miroirs dans l'URL des sources (see 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 name dans l'URL : ce n'est pas très utile et si le nom change, l'URL sera probablement erronée.

Lorsque vous envoyez un correctif à la liste de diffusion, utilisez [PATCH] ... comme sujet.  Vous pouvez utiliser votre client de courriel ou la commande git send-email (see 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 à NNN-done@debbugs.gnu.org.

Envoyer une série de correctifs
-------------------------------

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