Réorganisation du Wiki #45

Dans l'optique d'aider les nouvelles contributions, je pensais faire une page de Wiki contenant :

Les liens vers les tutos d'installation
Un document d'architecture qui permette de mieux comprendre comment est organisé le site (modèles, routes, templates, etc.).
Les points intéressants à prendre en compte lors des premières contributions

J'en profite pour demander aux nouveaux contributeurs les points bloquants

Edit:

Le but est de réorganiser le Wiki, de compléter la documentation manquante, et de fournir des schémas d'architecture pour que ce soit plus facile à prendre en main.

La page Environement de dévelopement est peutêtre une piste à retravailler pour la mise en place de l'environnement de dev.
À commencer par :

Est-ce réèlement utile d'avoir nginx dans l'env de dev ?
Et uwsgi ?

En pratique ils ne sont réèlement utiles que en prod, et encore… là la conf n'est pas la même.

Que faire de la VM de dev proposé dans la page Utiliser la machine virtuelle de dévelopement ?

Il y à des duplications des explications entre Environement de dévelopement et demarer le serveur flask.

On à une page qui résume l'utilisation de git et une autre qui donne des resources utiles, on peut se baser dessus pour crèer une vrai page pour les nouveaux contributeurs.

Cette issue risque de se transformer en une issue sur l'organisation du wiki… désolé.

C'est le setup normal, après on peut faire du flask run mais dans ce cas j'aimerais bien garder le tutoriel nginx quelque part.

La VM je laisse voir Darks, c'est lui qui gérait à l'époque donc j'ai pas vraiment suivi...

Cette issue risque de se transformer en une issue sur l’organisation du wiki… désolé.

Non non c'est le bon endroit pour en parler.

J'ai bien fait un petit truc en local, mais j'hésite à le mettre, j'aimerai un wiki qui soit réèlement opérationnel pour tout le monde.

Comme c'est un git je peut faire une nouvelle branche, ou annuler mes commits plus tard, mais annuler un commit déjà push c'est crade, non ? Et je sais pas comment gitea va digérer ça… est-ce que ça passe bien un wiki à plusieurs branches ?

j’aimerais bien garder le tutoriel nginx quelque part.

Ça peut aller dans VPS-Config ça. Typiquement j'ai déjà commit les config Nginx à jour avec les nouveaux assets statiques (avatars et PJ).

Que faire de la VM de dev

Je ne la maintiens plus, donc je préfère l'abandonner. Un bon tuto sur comment monter l'environnment de dev sera plus maintenable qu'un VM que personne n'utilise.

Cette issue risque de se transformer en une issue sur l’organisation du wiki…

C'est le but de ce ticket. Je peux le renommer pour qu'il soit plus explicite 😄

J’ai bien fait un petit truc en local, mais j’hésite à le mettre, j’aimerai un wiki qui soit réèlement opérationnel pour tout le monde.

N'hésite pas à pousser tes modifications. Au passage au taf on utilise la syntaxe 00-Nom pour les pages, ça permet directement de les trier dans le bon ordre. Ou du moins de forcer la page d'accueil en haut de la liste.

Je te propose de préfixer tes pages avec des nombres, comme présenté au dessus, et de pousser directement sur le Wiki. C'est pas grave si y'a de la duplication au début, de toute façon ça peut pas être pire qu'aujourd'hui. 😅

De manière générale, il faut se poser la question de comment organiser le Wiki, quels contenus regrouper, etc. On peut déjà séparer trois groupes triviaux, à savoir

l'installation de l'environnement
l'architecture du projet
les conventions utilisées (code, commits, …)

Après faut arriver à redécouper en plus petits bouts, ajouter d'autres catégories, etc. C'est pas forcément évident, mais le point de vue de quelqu'un qui connait peu le projet est d'autant plus apprécié : la doc est faite pour ce genre de personnes. 😉

C'est Push… mais je doit fix les liens qui sont tout cassés

PS: Les liens sur la page 00-Home sont fixé, à voir avec le reste

Au passage pour l'environnement, j'ai pensé à écrire quelques playbooks Ansible pour qu'on déploie plus entièrement à la main. Je vois quelques gros avantages à ça :

on sauvegarde la configuration du VPS quelque part
c'est plus simple à (re)déployer si on change de machine
un dev qui veut se monter une VM de dev n'a qu'à exécuter les playbooks

Et quelques avantages mineurs :

ça n'ajoute rien comme paquet à installer sur le serveur
ceux qui veulent s'en passer peuvent s'en passer
on monte en compétence sur un outil largement diffusé

Poke @Breizh pour avoir son avis.

Ça rejoint le ticket #18, je le ferme en tant que duplicate

À la limite… si on est sous nunux… on peut scripter un truc en shell pour le setup du venv. Un autre pour sourcer le venv et run flask, et simplifier les manips à faire(refaire) à chaque fois.
Et placer les ansible à côté, tout en laissant un peu de doc sur comment faire si on veut faire à la main(ou sans venv). Mais pour un débutant ça peut être plus simple de faire un simple bash setup.sh que de faire toute la suite des commandes.

Puisque le wiki à légèrement été réorganisé.
On peut préciser qu'on veut un tris des tutos et pages du wiki en plus d'en ajouter et re-écrire.

Ping @Darks @Lephenixnoir est-ce que l'état actuel du wiki vous va ?

Très satisfait de mon côté. Il y a des trucs pas à jour (le master script notamment que j'ai modifié "récemment") mais pour ce qui est organisation et présentation du contenu je trouve ça très bien. À relire les commentaires précédents je crois que ça répond aux attentes de l'époque aussi.

Éventuellement si le nombre de pages devient grand je proposerai de les nommer hiérarchiquement, presque litérallement "Installation / x" ou "Code / Modèles / y" histoire de mieux les ordonner que les numéros.

Je pense qu'on peut considérer cette issue comme résolue, et soit la fermer soit la garder pour discuter plus tard :)

Ok, je repasserai pour mettre a jour la partie sur le master script.

Je ferme l'issue et si besoin on la réouvrira ou on peut en créer une nouvelle plus tard