Une approche pratique des fichiers TOML et de la gestion des succursales distantes

Cette semaine j'ai eu l'occasion de travailler sur des fichiers TOML Config et de revoir une modification apportée sur mon dépôt en extrayant les modifications localement depuis un fork de mon projet

Que sont les fichiers TOML

TOML (Tom's Obvious Minimal Language) est un format de fichier de configuration qui utilise une simple paire clé-valeur pour définir les variables de configuration à utiliser dans un programme

un fichier TOML pourrait ressembler à ceci

[dependencies]
requests = ">=2.25.0"
flask = { version = "2.0.1", optional = true }


[database]
type = "postgres"
host = "localhost"
port = 5432
username = "admin"
password = "password123"

[database.settings]
pool_size = 5
timeout = 30

La façon dont ces fichiers fonctionnent consiste à utiliser un analyseur pour analyser le contenu du fichier TOML, puis à utiliser les variables du programme

La raison pour laquelle il est préféré à JSON ou YAML est qu'il est facile à écrire et à comprendre par un humain et qu'il réussit dans la gestion de la configuration.

Mon cas d'utilisation de TOML

Cette semaine, j'ai eu l'opportunité de travailler sur un excellent projet, Addcom. Il s'agit d'un outil CLI qui récupère des exemples de fichiers et génère des commentaires en ligne pour les fichiers, il utilise l'API Groq pour générer les commentaires pour le fichier

Désormais, lors de l'appel de l'outil CLI, l'utilisateur peut définir certains arguments facultatifs qui peuvent être utilisés lors d'une requête API à Groq, qui sont les suivants

• model - le modèle à utiliser pour l'API Groq
• stream - il s'agit d'une valeur booléenne qui spécifiera si la sortie doit être diffusée ou non
• api_key- la clé API à utiliser pour le Groq
• contexte- chemin d'accès au fichier qui fournirait du contexte au LLM

Maintenant, il serait vraiment frustrant pour l'utilisateur de spécifier encore et encore la même valeur d'argument dans l'outil CLI, pour éviter cela, j'ai implémenté un fichier TOML qui contiendrait tous les paramètres de configuration et les valeurs à utiliser afin que plutôt au lieu de spécifier les paramètres de configuration à plusieurs reprises, le programme peut simplement consulter le fichier TOML et appliquer les paramètres pertinents.

Le flux logique du programme serait le suivant

1) L'outil CLI sera appelé dans le terminal
2) S'il n'y a aucun argument, les variables du fichier TOML seront utilisées
3) Si les variables du fichier TOML sont erronées alors elles ne seront pas utilisées, le programme se terminera avec le code d'erreur 0
4) Si l'utilisateur fournit également les arguments de ligne de commande avec le fichier TOML, les arguments de ligne de commande seront utilisés
5) L'opération est effectuée avec les bons arguments

Pour trouver un aperçu descriptif du problème que j'ai soulevé dans le dépôt, cliquez ici

de plus, pour trouver le PR pertinent pour le même, cliquez ici

Travailler avec des télécommandes Git

Jusqu'à présent, chaque fois que je devais fusionner un PR, je devais le faire via Github, mais cette fois-ci, j'ai trouvé un moyen vraiment excitant de faire la même chose localement

J'avais quelqu'un qui travaillait sur l'implémentation d'une fonctionnalité pour mon outil CLI, la même personne a créé un fork de ma base de code et a commencé à implémenter la fonctionnalité, une fois qu'elle a été implémentée, elle a poussé le code vers sa branche thématique sur son fork.

Maintenant, avant de pouvoir approuver les modifications, j'ai dû examiner les modifications du code et m'assurer qu'elles fonctionnaient et ne causaient pas de problèmes sans précédent

Pour y parvenir, j'ai mis en œuvre les étapes suivantes

git remote add <user_name> <user_name/fork>

la commande ci-dessus ajouterait une connexion à distance à un fork de ma base de code

git fetch <user_name/fork>

cela récupérerait toutes les nouvelles branches du référentiel distant et mettrait à jour mon dossier .git local

git checkout -b review-change <user_name/fork>

cela créerait une nouvelle branche appelée révision-changement qui serait construite au-dessus de la branche sujet, afin de pouvoir réviser les modifications apportées par la personne

Une fois que j'aurai examiné les modifications, je ferai ce qui suit

git checkout main
git merge review-change

cela effectuerait une fusion rapide car aucune modification n'a été apportée sur mon réseau principal local

git push origin main

cette commande serait exécutée pour transmettre les modifications fusionnées à mon référentiel distant, ce qui fermerait alors automatiquement le PR que la personne avait ouvert.

Conclusion

Cette semaine, j'ai acquis une expérience précieuse en travaillant avec les fichiers de configuration TOML et en gérant les workflows Git pour les contributions de code. La mise en œuvre de TOML a permis aux utilisateurs de définir des paramètres de configuration réutilisables pour le projet Addcom, simplifiant ainsi l'utilisation de l'outil CLI et améliorant le confort d'utilisation. De plus, j'ai appris à réviser et à fusionner localement les modifications du fork d'un contributeur en ajoutant son référentiel distant, en récupérant les modifications et en effectuant une fusion rapide.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!