gitlab hints / aide

Git
Workflow Git	trunkbaseddevelopment.com
Semantic versioning	semver.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).

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.