Mots-clé : git

Django et git : bonnes pratiques / idées pour faire du CI

Conseil d’un ami :

  • gitlab n’est pas 100% opensource, ils proposent une édition communautaire limité et la totalité des fonctionnalités est dispo avec la version entreprise, leur modèle économique c’est de brider la version CEE (community) dans pas mal de coin pour te pousser à prendre une licence, perso je trouve que c’est plus un freeware qu’autre chose
  • gitlab est pas mal mais honnêtement pour l’avoir beaucoup (vraiment beaucoup) utilisé dans le passé ce n’est pas la meilleur alternative.

Si tu cherche à mettre en place un truc je te conseille fortement de jeter un œil à :

Cette stack est un peu plus compliquée à mettre qu’un gitlab, mais c’est très puissant, surtout la partie gerrit qui transcende la manière de faire des revues de code.

Si le code Django / Python n’est pas correct, il y a des méthodes pour améliorer les choses notamment :

  • https://nvie.com/posts/a-successful-git-branching-model/
  • https://semver.org/

Il est également important de mettre en place un système de « core developer » même au sein d’un projet privé en entreprise, afin de garantir la cohérence des données et l’intégrité de l’historique. En effet, si tout le monde à les droits d’écriture sur tout, ça finira toujours à un moment donné à partir dans tous les sens… L’idée, c’est de donner les droits d’écriture à seulement 2-3 personnes de confiance qui ont un certain niveau et à tous les autres imposer de faire des forks dans leur namespace gitlab et de proposer des merge request (l’équivalent des pull requests avec github). Ainsi, la revue de code est obligatoire et il n’est plus possible de merger du mauvais code… et les développeurs « standard » (sans droits donc) ont juste 2-3 commandes de base à connaître pour bosser avec les autres. Sans ce genre de système cela ne peut pas réellement fonctionner car git à été developpé pour ce mode de fonctionnement (au même titre que svn et d’autres gestionnaire de version) et donc son workflow est idéal dans ce cadre.

Fonctionner comme ça m’a permis de :

  1. coder un petit robot qui réagissait au merge requests proposé et donc qui checkait tout un tas de choses automatiquement et qui proposait des commandes si les choses n’allaient pas
  2. responsabiliser les gens de l’équipe en les rendant responsables de leur propre forks
  3. faire monter en compétence l’équipe qui était ultra frileuse à faire du versionning puis au final à pris goût au truc…

J’ai fais des petites formations au début pour leur expliquer l’intérêt et expliquer la sémantique des changement et qu’il est important de penser ses commits de manière propre. Cela permet :

  • dans certains cas de retirer (revert) des bugs complet d’un seul coup,
  • de faire du debug de manière automatique sans rien toucher et de trouver les changements responsable d’un bug (git bisect),
  • de faire un gain énorme de qualité au final
  • d’avoir des historiques clairs avec des messages de commit ayant une réelle plus value (exemple)
  • d’automatiser tout un tas d’actions qui vont augmenter la qualité globale du projet et vont réduire les taches inutiles et donc laisser plus de temps pour les trucs fun à faire.

C’est gagnant gagnant, mais au début les gens râlent… il faut juste s’y préparer et avec le temps ils changent d’avis !

Gitlab Continuous Integration

gitlab CI

Gitlab CI (Continuous Integration)

Layer A set of read-only files or commands that describe how to set up the underlying system beneath the container. Layers are built on top of each other, and each one represents a change to the filesystem.
Image An immutable layer that forms the base of the container.
Container An instance of the image that can be executed as an independent application. The container has a mutable layer that lies on top of the image and that is separate from the underlying layers.
Registry A storage and content delivery system used for distributing Docker images.
Repository A collection of related Docker images, often different versions of the same application.

Docker memo

Docker memo

docker images List all images present on host.
docker rmi To remove an image you no longer plan to use.
docker run [image] Start a container of the image [image]. If the image is not present on the host, it will go out to docker hub and pull the image down, it's only done the first time. For the subsequent executions, the same image will be re-used.
docker run [image] -d Start a container of the image docker run [image] in detached mode = in the background.
docker run -p [src]:[dst] [image] -d Like rStart a container of the image docker run [image] in detached mode = in the background.
docker pull [image] Like docker run but only pull the [image], not run it.
docker exec [container name] [command] Runs the command [command] on a running container.
docker ps List all running containers with informations such as container id, the image used for it.
docker ps -a To see all containers running or not.
docker ps A collection of related Docker images, often different versions of the same application.
docker stop [name] To stop a running container.
docker rm [name] rm = remove container. To remove a stopped or exited container permanently = stop using space.
docker rmi rmi = "remove images". To remove an image you no longer plan to use.
docker rmi To remove an image you no longer plan to use.

CI / git / gitlab / github

gitlab hints / aide

Git

Workflow Gittrunkbaseddevelopment.com
Semantic versioningsemver.org
Commit messages, règles de base gist.github.com/robertpainsi
Conventional commits conventionalcommits.org
Full refresh à partir du develop (si problème ou autre) git reset --hard origin/develop
git pull
Rafraîchir (à la main) une branche locale (si problème ou autre) git checkout master
git branch -D develop
git fetch
git checkout develop
git pull
Synchroniser le local avec le remote git fetch
Pour faire une nouvelle branche git checkout -b [nom de la branche]
Pour changer de branche git checkout [nom de la branche]
git pull
Sous-module : ajouter un git qui vient d'un autre repo git submodule add [nom du repo] [dossier dest]
Exemple concret qui a fonctionné pour moi : git submodule add https://github.com/goldfire/howler.js.git static/vendors/howler.js

Si erreur git qui parle de répertoire, demander à supprimer le dossier du cache : git rm --cached [dest. ex: static/vendors/howler.js]
Sous-module : ajouter un git qui vient d'un autre repo git submodule add [nom du repo] [dossier dest]
Exemple concret qui a fonctionné pour moi : git submodule add https://github.com/goldfire/howler.js.git static/vendors/howler.js

Si erreur git qui parle de répertoire, demander à supprimer le dossier du cache : git rm --cached [dest. ex: static/vendors/howler.js]
Sous-module : ajouter un git qui vient d'un autre repo git submodule add [nom du repo] [dossier dest]
Exemple concret qui a fonctionné pour moi : git submodule add https://github.com/goldfire/howler.js.git static/vendors/howler.js

Si erreur git qui parle de répertoire, demander à supprimer le dossier du cache : git rm --cached [dest. ex: static/vendors/howler.js]
Sous-module : : sur un autre PC mettre à jour avec tous les sous-modules Si git pull ne met pas à jour les sous-modules, c'est que ce qui gère les sous-modules sous git n'est pas initialisé :
git submodule update --init
Pour changer de branche git checkout [nom de la branche]
git pull
Pour changer de branche git checkout [nom de la branche]
git pull
Git global setup
Sur PC dev
git config --global user.name "Olivier Pons"
git config --global user.email "monmail@mail.com"
Clone gitlab » dev
Push dev » gitlab
git clone git@gitlab.com:olivier.pons/ajeter.git
cd ajeter
touch README.md
git add README.md
git commit -m "add README"
git push -u origin master
Init. projet pas vide:
Clone dev » gitlab
cd existing_folder
git init
git remote add origin git@gitlab.com:olivier.pons/ajeter.git
git add .
git commit -m "Initial commit"
git push -u origin master
Git existant sur dev
Clone dev » gitlab
cd existing_repo
git remote rename origin old-origin
git remote add origin git@gitlab.com:olivier.pons/ajeter.git
git push -u origin --all
git push -u origin --tags
Autre Git existant sur gitlab
Clone gitlab » dev
git clone git@gitlab.com:adresse/repo/sur/gitlab/monprojet.git
Cloning into 'monprojet'...
remote: Enumerating objects: 308, done.
remote: Counting objects: 100% (308/308), done.
remote: Compressing objects: 100% (192/192), done.
Receiving objects: 63% (195/308)
Receiving objects: 100% (308/308), 93.34 KiB | 463.00 KiB/s, done.
Resolving deltas: 100% (169/169), done.
cd monprojet
git checkout -b nom-de-la-branche remotes/origin/nom-de-la-branche
Donc en local, on a en local nom-de-la-branche liée à la branche distante remotes/origin/nom-de-la-branche.
A partir de là commit, push et pull fonctionnent.
Si des branches ont été ajoutées au remote :
Synchroniser le git local avec le remote
 git remote update origin --prune

Requirements

requirements

Le résultat du pip freeze permet d'avoir un "snapshot" des versions exactes utilisées, cela peut éviter certains bugs. Dans tous les cas, il faut prendre en compte les dépendances dès le début du projet et tout au long de son cycle de vie.
Une bonne pratique quand on utilise pip est de structurer ses dépendances de la manière suivante : ​
  • Un fichier requirements_base.txt avec les dépendances communes, par exemple : pynsq==0.8.2
    requests==2.19.1
    xlrd==1.1.0
    openpyxl==2.5.7
    python-datauri==0.2.8
  • Un fichier requirements_dev.txt dépendant de requirements_base.txt ne contenant les dépendances uniquement nécessaires pour le développement, test, CI, par exemple :
    -r requirements_base.txt
    pylint
  • Un fichier requirements_prod.txt dépendant de requirements_base.txt contenant les dépendances uniquement nécessaire à la production : -r requirements_base.txt
    gunicorn==19.7.1
  • Et un fichier requirements.txt qui ne sert que de lien à celui de prod (certaines plateformes style heroku utilisent celui-ci par défaut) -r requirements_prod.txt
Le développeur installe requirements_dev.txt, le déploiement en prod utilise requirement_prod.txt ou requirements.txt. ​ Tout ceci permet d'avoir des environnements reproductibles avec des versions figées, et de ne pas avoir à installer des dépendances supplémentaires à la main (par exemple gunicorn en prod).
Commentaires fermés sur CI / git / gitlab / github Publié dans Mots-clé , , ,

Python » PyPI

Contribuer à une librairie Python

Principes

  • Faire un dossier (ex : source)
  • Dans source, cloner la librairie à laquelle on veut contribuer via
    git clone [repo concerné]
  • Faire un dossier pour l’environnement pip (ex : pip_env_lib)
  • Dans pip_env_lib, installer l’environnement pip via pipenv install
  • Dans pip_env_lib, lancer le « shell pip » via pip shell
  • Rarement documenté et important :
    – aller dans le dossier source
    – faire pip install -e .

pip install -e . (n’oubliez pas le . qui change tout, cela indique le répertoire à utiliser) signifie « si jamais le shell Python en cours essaie d’accéder à la librairie à laquelle on veut contribuer, aller la chercher dans source ». En fait, concrètement parlant, pip fait simplement un lien symbolique entre le dossier source d’installation de pip (ici c’est pip_env_lib), et le dossier source. N’oubliez pas que cela ne concerne le shell Python en cours (ici pip_env_lib).

L’avantage pratique de ce « lien symbolique », c’est qu’il est directement relié au code source. Donc, lorsqu’on modifie le code source de la librairie elle-même (dossier source), elle est immédiatement disponible. Si on fait donc des fichiers de tests unitaires, il suffit de les relancer, les modifications du code source sont toujours instantanément prises en compte. Toujours dans le shell Python en cours (ici pip_env_lib).

Résumé : exemple de code

mkdir [source]
cd [source]
git clone [repo concerné]
cd ..
mkdir [pip_env]
cd [pip_env]
pipenv --python 3 install
pip shell
pip install -e .

.. et les modifications dans [source] peuvent commencer !


PyPI : nouveau package / contribution

La documentation détaillée en anglais se trouve ici.
Bien meilleure que ce qui suit, mais longue, longue…

Voici les notes prises à la volées, d’un contributeur plutôt habitué à faire des contributions dans le monde Python.
Toute nouvelle note / correction éventuelle est la bienvenue.

Il y a trois choses différentes qu’on a tendance à confondre, mais qui n’ont fondamentalement aucun rapport. On a tendance à les confondre parce qu’on essaie d’utiliser, pour des raisons pratiques, le même nom, mais dans trois cadres différents.
Ces trois choses à bien dissocier sont :
le nom du package PyPI : dans le fichier de déploiement setup.py, il est défini dans le paramètre « name » de la commande setup(). C’est ce qui est vu dans PyPI.
le nom du projet qu’on met dans github : c’est le répertoire qui contient tous les fichiers du projet (= il peut être totalement différent, en général on s’arrange pour les appeler d’un nom différent) = c’est ce qu’on clone dans l’ordre git clone [repo concerné]
– le développeur final qui fait un « import » dans son code : ce module là peut être aussi différent, car c’est du Python. En général, c’est le répertoire de premier niveau du package (il doit contenir, bien sûr, « __init__.py » pour être vu comme un package et importable par Python). En général : « from [ma lib] import [quelque chose]« .

En général, on essaie de s’arranger pour que le nom du package sur PyPI soit le même que le nom du package dans le code Python même.
Mais s’il est déjà pris (dans un des trois contextes), il faut forcément utiliser un autre nom, et c’est là qu’il faut faire attention à ne pas se mélanger les pinceaux.

Pour faire un nouveau package sur PyPI le plus homogène possible :

  1. essayer de faire un projet « vide »
  2. faites une version squelette « alpha1 »
  3. faites une mise à jour sur PyPI : si ça fonctionne, alors vous pouvez continuer. Sinon, il faut utiliser un autre nom

Versionning

Dans PyPI, les versions sont obligatoirement du type «a.b.c».
En général :
[a].[b].[c]
[a] = fonctionnalités totalement nouvelles / incompatibilité
[b] = améliorations / nouvelles "petites" fonctionnalités
[c] = correctifs bogues

setup.py

Lorsque vous faites une nouvelle contribution, vous devez obligatoirement fournir un fichier setup.py.
Dans ce fichier, setup.py, il y a une fonction, ici aussi, obligatoire : setup().
Cette fonction, parmi tous les paramètres, a un paramètre particulier : classifiers qui permet au niveau de PyPI de dire « ce package est rangé dans telle(s) catégorie(s) ». La liste des expressions disponibles se trouve ici.

weechat

weechat hints / aide

Côté utilisateur

La souris Quand on aimerait cliquer :
/mouse disable
Pour la remettre :
/mouse enable
Documentation Raccourci : cliquer sur le lien :
– Message privé
– Raccourcis clavier

Configuration

Toujours installer v2+ et pas moins https://weechat.org/download/
Fichier de conf :
~/.weechat/
Weechat = une seule instance.
Conf. chargée en entier ici :
~/.weechat/
Pour plusieurs instances, copier tout le dossier, ex :
cp -R ~/.weechat ~/.weechat2
Puis lancez en précisant weechat -d ~/.weechat2
Lancement + connexion auto Exemple de code :
weechat -r '/server add freenode irc.freenode.net; /connect freenode -nicks=Olivier; /set irc.server.freenode.username "Olivier2"; /set irc.server.freenode.realname "Olivier Pons"; /set irc.server.freenode.autojoin "#prognosis-dev"'

Plugins

Situés dans :
~/.weechat/
Plugins Python ici :
~/.weechat/python
Chargement manuel Exemple Python / plugin arespond.py :
/script load arespond.py
Chargement automatique Exemple Python / plugin arespond.py :
Faire un lien symbolique :
cd ~/.weechat/python/autoload
ln -s ../arespond.py arespond.py
Options / switches Définir une option manuellement :
/set plugins.var.python.[SCRIPT_NAME].[option]="[valeur]
Appuyer sur TAB pour autocompléter
Au pire lire les options dans le code même.
Exemple Python / plugin arespond.py :
Les options sont en « camelCase », mais elles sont toutes transformées en minuscules dans weechat.
Il y a trois options marquée dans le code:
"muted"
"respondAfterMinutes"
"responderText"
Donc pour y accéder, il suffit de taper :
/set plugins.var.python.arespond.[tab]
Et les trois options seront affichées sur la ligne du dessus, il suffit d’autocompléter.

Django et git (git « pur », pas « github »)

Si jamais vous décidez d’être un vrai guerrier, un de ceux qui veulent tout maîtriser, un de ceux qui, quand on leur donne des ordres, peuvent les refuser (oui c’est rare), et si vous voulez prendre des responsabilités, bref, si vous en avez : faites vous votre propre serveur git !

Je ne décrirai pas comment installer un serveur git sous Linux tellement c’est simple. Et je ne décrirai pas non plus comment faire ça sous Windows : pour des raisons de sécurité, de fiabilité et d’éthique, évitez Windows un point c’est tout.

Donc, sous Linux :

  • Créez un dossier dans lequel vous mettez toutes vos sources (scp est votre ami si vous êtes sur un PC et que vous voulez faire cela sur un autre PC)
  • Supposons que l’on est dans /web/htdocs/interro/htdocs
  • Créez un fichier .gitignore
  • Dans ce fichier, mettez ceci :
    *.pyc
    __pycache__
    myvenv
    db.sqlite3
    /static
    .DS_Store

    Cela signifie « ignore tous ces fichiers (.DS_Store est pour les personnes sous Mac (non je ne vous en veux pas, je suppose que vous ne connaissez pas bien l’histoire de l’informatique pour avoir acheté Apple)) » pour toutes les personnes qui vont cloner ce dossier
  • Ensuite, ajoutez tous les fichiers ainsi : git add --all .
  • Et commitez (oui je sais ce n’est pas français) ou « appliquez » les modifications c’est à dire l’ajout de tous les fichiers ainsi : git commit -m "My application, first commit"
  • Vous devriez avoir un paquet de fichiers ajoutés, vérifiez que tout est bien enregistré en demandant l’état via git status. Vous devez avoir un messsage ressemblant fortement à
    nothing to commit (working directory clean)
  • Vous êtes prêts ! Vous avez crée un repository (j’ai la flemme de traduire en français), et vous y avez appliqué tous vos fichiers. Il ne vous reste plus qu’à le cloner à distance
  • (Update) : par défaut, le serveur travaille sur la branche d’origine (« master »). Seul problème : si vous essayez de faire un « push » à partir de votre PC de développement, git ne sera pas d’accord pour faire un « push » sur la branche « master ». Je pense que c’est pour des raisons de sécurité ou autre, mais c’est plutôt récent, avant cela fonctionnait. La solution : dites sur le serveur de travailler sur une autre branche c’est via l’ordre checkout. Notez bien : c’est sur le serveur. Je ne trouve pas ça très cohérent, j’aurais dit que c’était au client de dire sur quelle branche il veut « push », mais je dois manquer quelque chose… j’ai vraiment beaucoup de lacunes git. Bref. Exemple : git checkout -b development.
  • Ensuite il vous suffira de faire un git clone (dans PyCharm, c’est le menu VCS » git » clone)

Bien sûr, comme tous les gestionnaires de version délocalisés, il vous faudra toujours trois étapes pour valider vos modifications :

  1. Appliquer les modifications en local (git commit -m "mon message expliquant les modifs")
  2. Essayer de récupérer toutes les dernières modifications du repository (git pull) vers votre code « local », au cas où d’autres personnes auraient « pushé » des modifications
  3. Envoyer vos modifications sur le serveur pour qu’elles soient accessibles à tout le monde (git push)

github : mémo pour les pressés

Voici un mémo de mon expérience très rapide de github, qui n’est destiné à l’origine qu’à moi, mais que je partage pour ceux qui voudraient aller vite :

  • Forker un repo : c’est à dire, faire « sa » propre branche d’un source pour pouvoir travailler dessus.
    Sur github : en haut à droite du « repo » principal, vous avec le menu « fork ». Cliquez dessus et c’est fini !
    Details »» ici ««
  • Copier en local
    De l’étape précédente, vous aurez une adresse genre
    https://github.com/VOTRE-USERNAME/repo-qui-vous-plait
    Faites :
    git clone https://github.com/VOTRE-USERNAME/repo-qui-vous-plait
    et git fera un copier coller en local des sources github
  • Ajouter le repo d’origine pour les futures synchronisations :
    Copier coller l’URL du repo d’origine qui est sur github :
    git remote add upstream https://github.com/repo-qui-vous-plait
  • Assurez-vous que tout est ok :
    Avec ce code :
    git remote -v
    Vous devriez avoir :
    origin https://github.com/VOTRE-USERNAME/repo-qui-vous-plait.git (fetch)
    origin https://github.com/VOTRE-USERNAME/repo-qui-vous-plait.git (push)
    upstream https://github.com/POSSESSEUR-DU-REPO/repo-qui-vous-plait.git (fetch)
    upstream https://github.com/POSSESSEUR-DU-REPO/repo-qui-vous-plait.git (push)
  • Ensuite ces étapes en boucle :
    • Repo origine distant vers local :
      Ce qui a été fait par les autres sur le repo général (s’il y en a) vers local.
      git fetch upstream
    • Repo perso distant vers local :
      Ce qui a été fait par les autres sur votre repo (s’il y en a) vers local.
      git checkout master
      puis
      git merge upstream/master
      Details »» ici ««
    • Noter vos modifications en local :
      Préciser à git de chercher (1) toutes vos modifications, option « a » (2) le commentaire, option « m ».
      git commit -am "Mon commentaire"
    • Appliquer vos modifications à distance :
      git push
      Details pas de github, mais en français et très bien faits :
      »» ici ««