Rendre ZdS installable en 30 minutes

gasche commented 10 years ago

J'ai pas mal cassé les pieds aux gens de PdP pour que leur site soit facile à installer. Du logiciel libre c'est bien, mais pour être vraiment ouvert il faut que le site soit facile à installer.

Le but ultime c'est que quelqu'un qui n'a jamais touché au code puisse passer de la case "tiens il y a une typo dans tel menu" à "j'envoie un patch sur github" en 30 minutes maximum. Je viens de passer 27 minutes à essayer d'installer PdP, sans succès, parce que votre documentation n'est pas encore assez bonne.

J'ai essayé de suivre la procédure d'installation de ZdS, mais ça ne marche pas. J'ai fait comme ceci:

J'ai lancé un gros sudo apt-get install avec les dépendances listées sur la page install-linux (je suis sous une Debian Sid pas trop à jour); il aurait été sympa de réunir toutes ces dépendances en une seule commande, là il faut collecter les noms de paquets un par un en faisant du copier-coller
Comme ça prenait du temps j'ai regardé la partie frontend en parallèle. Pourquoi faut-il télécharger une archive pack.zip du site ? Les documents statiques qui sont dedans ne sont-ils pas versionnés ? En jetant un œil à ce que j'obtient dans dist/, il y a l'air d'avoir une forte redondance avec ce qui est déjà dans assets. Pourquoi ne pas tout mettre dans le dépôt git ? (Ou un dépôt git séparé zds-static; github crée automatiquement des archives et en plus c'est versionné.)

Toujours sur la partie frontend. Je ne comprends pas pourquoi il faut utiliser npm -g (j'ai fait avec sans sudo il a râlé, alors j'ai fait sans, ensuite bower m'a dit qu'il y tenait, mais ça n'a pas l'air d'être ce qui a posé problème). L'installation échoue avec une erreur mystérieuse qui n'est pas de votre faute, j'imagine:

bower modularized-normalize-scss#~3.0.1       not-cached git://github.com/hail2u/normalize.scss.git#~3.0.1
bower modularized-normalize-scss#~3.0.1          resolve git://github.com/hail2u/normalize.scss.git#~3.0.1
bower modernizr#~2.8.2                           ECMDERR Failed to execute "git ls-remote --tags --heads git://github.com/Modernizr/Modernizr.git", exit code of #128

Additional error details:
fatal: unable to connect to github.com:
github.com[0: 192.30.252.130]: errno=Connection timed out

Côté backend, après la réussite du apt-get install, j'ai regardé la partie Lancer ZdS du document d'installation pour Linux. C'est inutilisable puisque cela suppose qu'on utilise virtualenv... sans expliquer comment mettre en place virtualenv. Je n'ai pas de ../bin/activate depuis le répertoire racine du projet (je doute d'ailleurs qu'il faille utiliser le chemin .. dans ce cas, mais il n'y a pas de ./bin non plus), et du coup le pip install échoue car il essaie d'installer des choses globalement et n'a pas les droits roots.

.

Pour résumer, pour l'instant ZdS ne passe pas le test "install en 30 minutes pour un noob", et je crée ce ticket pour que ce soit le cas dans le futur le plus proche possible.

Pour résumer:

Je ne comprends pas quel est le rôle de pack.zip et ça n'a pas l'air d'être une super idée
Il y a des erreurs dans l'installation du frontend qui ne sont pas de votre ressort.
Il faut expliquer comment utiliser virtualenv en supposant que les gens ne connaissent pas (ou ont oublié) ou alors fournir les commandes qui n'en dépendent pas

SpaceFox commented 10 years ago

Le pack.zip est là parce que les ressources front sont compilées d'un format développable (dans Git) en un format utilisable (qui est dans ce pack.zip). Demander à tout le monde de compiler ces ressources serait infâme et très long. Il semblait être une mauvaise idée de versionner les versions compilées (je laisse les dev front développer).
Je laisse les dev front voir.
On partait du principe que le dev sous Linux qui a assez de connaissances pour installer un site comme celui-ci et proposer un patch savait faire une recherche pour installer un virtualenv sur sa machine, mais c'est peut-être bien une erreur.

Si tu as des améliorations à faire dans la doc, n'hésite pas à proposer directement une PR :)

gasche commented 10 years ago

(1) Pour le pack.zip, il me semblerait raisonnable de versionner ce fichier .zip dans le dépôt, et de cacher sa manipulation (à l'utilisateur qui installe) par un script. Si vous faites aujourd'hui l'archive à la main, mise à jour quand vous y pensez, c'est une amélioration claire du processus. Si vous avez déjà un bot qui automatise la mise en place de l'archive, devoir le versionner serait sans doute moins pratique que l'existant; mais comment ferez-vous quand vous voudrez "remonter dans le temps" pour tester une régression introduite il y a trois mois, en remettant les ressources d'origine ?

(3) La question n'est pas de "savoir faire une recherche", mais que ça marche rapidement de simplement. Je pourrais faire une recherche mais si c'est pour un patch tous les ans, que j'oublie entre temps, et que j'ai par ailleurs des dizaines de choses intéressantes à faire, pourquoi m'embêter ? Il faut que le coût d'entrée "je passe de rien à une version de dev utilisable" soit le plus bas possible pour avoir des contributeurs occasionnels.

Axylium commented 10 years ago

Il faut expliquer comment utiliser virtualenv en supposant que les gens ne connaissent pas (ou ont oublié) ou alors fournir les commandes qui n'en dépendent pas

@pierre-24 a rajouté la procédure ce soir, d'installation de virtualenv.

Alex-D commented 10 years ago

Pour le front, je peux t'assurer que c'est inutile de versionner le pack.zip. C'est dédié aux gens qui veulent toucher au back uniquement : ils téléchargent le zip, le dezippent et n'ont pas besoin d'installer quelque dépendance front que ce soit.

Remonter dans l'historique de ce pack est simple : on remonte dans l'historique des assets (la version de dev, et non la version compressée et optimisée qui se trouve dans /dist) et on génère le /dist à partir de cette version. Il n'y a aucun intérêt à allourdir le repo avec un zip de quelques Mo à chaque modification de style ou autre. Aucun intérêt non plus à versionner la version compressée des CSS/JS ou encore les sprites.

Le but de ce système c'est juste d'éviter d'installer les dépendances front pour tous les devs back (la majorité).

Le bug que tu as avec bower est connu, ça ne dépend pas de nous. Mais le -g pour global est normal. Sans ça, tu ne pourras pas utiliser bower en tant que commande : bower install machin nécessite donc que bower soit une commande connue, donc globale.

DevHugo commented 10 years ago

Que pensez-vous d'un script shell d'installation de zeste de savoir pour les distributions les plus connus ? (Je peux m'en occuper au besoin)

firm1 commented 10 years ago

Que pensez-vous d'un script shell d'installation de zeste de savoir pour les distributions les plus connus ? (Je peux m'en occuper au besoin)

Il y'a un ticket existant là dessus tu peux y aider

Sinon pour répondre pour le pack.zip, c'est juste la version compilé du dossier assets. De la meme manière que dans un programme en C par exemple, on versionne les sources, mais on ne versionne jamais l'executable. Etant donné que les sources (dossier assets) est versionné, on peut remonter dans l'historique quand on le souhaite.

Et donc, comme marqué dans la doc, le developpeur qui veut faire uniquement du back end va télécharger la version front-end déja compilé (dist.zip), mais celui qui veut faire du front-end va devoir installer les dépendances front-end (nodejs, gulp, bower) pour vérifier ses changements (en compilant lui même) dans les fichiers (JS, css, images)

gasche commented 10 years ago

Il me semble que ce qui ressort du ticket sur le script d'installation, c'est que personne ne sait vraiment quelles sont toutes les étapes à faire pour faire tourner le site en local. Autant je suis d'accord avec la conclusion (dans le ticket) qu'avoir un site tout-prêt pour chaque distribution n'est pas forcément très important, autant avoir une liste claire et complète me semble essentiel.

Merci à @pierre-24 pour la PR sur le readme; je re-tenterai une installation quand elle aura été mergée.

Merci à tous pour les précisions sur le pack.zip. Je ne trouve pas la documentation claire à ce sujet (c'est pour ça que j'ai demandé des clarifications). Quand j'aurai refait une tentative d'installation, je proposerai une PR pour clarifier cette partie.

gustavi commented 10 years ago

Pourquoi ne pas créer une VM (basée sur l'env de prod, Ubuntu ou Debian il me semble) prête à l'emploi avec juste le repo git à mettre à jour (avec éventuellement un script pour cela) ?

Ce n'est pas très compliqué à mettre en place et ça facilite grandement la vie de certains qui veulent juste faire une petite PR ou un morceau de dev front sans vouloir se taper l'installation de python et Django avec un environement virtuel, ce qui n'est pas chose aisée la première fois.

SpaceFox commented 10 years ago

Ben à la place de passer 30 minute à installer l'environnement, tu dois passer 1h à installer le bon environnement de virtualisation, télécharger la VM (2 Go minimum) et prendre le truc en main.

Pas sûr qu'on y soit gagnants.

Le 8 août 2014 16:26, Laville Augustin notifications@github.com a écrit :

Pourquoi ne pas créer une VM (basée sur l'env de prod, Ubuntu ou Debian il me semble) prête à l'emploi avec juste les repo git à mettre à jour (avec éventuellement un script pour cela) ?

Ce n'est pas très compliqué à mettre en place et ça facilite grandement la vie de certains qui veulent juste faire une petite PR ou un morceau de dev front sans vouloir se taper l'installation de python et Django avec un environement virtuel, qui n'est pas chose aisée la première fois.

— Reply to this email directly or view it on GitHub https://github.com/zestedesavoir/zds-site/issues/1350#issuecomment-51608874 .

gustavi commented 10 years ago

Ça peut être une solution. Virtualbox est très simple a installer, après faut 2-3 notions mais pas plus que pour installer toutes les dépendances.

Fulbert commented 10 years ago

J'ai hésité il y a quelques semaines à proposer cette solution de VM (perso j'ai installé ZdS sur une VM). Je pensais qu'on aller me crier dessus. :D

Mais c'est vrai que télécharger la VM peut-être pénible... Et si le but est d'avoir une installation propre de ZdS en 30 minutes, il faut alors avoir une connexion à 10MB+.

gasche commented 10 years ago

Trois choses.

D'une part, fournir une image veut dire qu'il faut mettre à jour l'image quand l'environnement de développement change. Ce n'est pas forcément gênant (il change moins souvent que le source), mais ça veut dire qu'il faut qu'il soit clairement spécifié, et donc le travail pour "décrire comment installer l'environnement" proprement et simplement sera utile aussi pour l'image. On peut continuer à chercher à avoir un "bon README d'installation" et regarder pour l'image en parallèle.

Ensuite, pour qu'un image soit facile à utiliser pour un débutant, il faudrait que deux conditions soient remplies:

on peut hacker le code du site en utilisant ses outils de développement habituel (qui vivent en dehors de l'image)
on peut interagir avec le résultat avec son browser habituel (cette condition est moins importante, au pire on embed firefox dans l'image et les gens testent de là)

Enfin, je crois que la taille n'est pas un soucis. Si l'image sert juste à faire tourner l'environnement de dev, pas besoin d'une couche graphique, donc on peut avoir quelque chose de petite (il y a des images de Ubuntu Server, par exemple, à 500MiB, on peut certainement faire quelque chose dans ces eaux-là). D'autre part, cliquer pour télécharger l'image, aller faire autre chose, et revenir une heure après n'est pas un problème; c'est beaucoup moins coûteux pour le débutant motivé que de passer le même temps à galérer pour installer l'environnement avec des commandes peu claires.

pierre-24 commented 10 years ago

J'aime vraiment bien vers quoi tourne la discutions :) (bien qu'à mon avis, elle devrait du coup, avoir lieu sur le forum). Pour la taille de la VM ... Je serait incapable de dire quel est la taille réelle du ZdS avec toutes ces dépendances, mais y'a quand même Pandoc dans le machin, qui ammène avec lui tout LaTeX, aka 1 PUTAIN DE GIGA DE PACKET USELESS (Troll, évidement). Donc, à moins que je me trompe, ça peut être lourd :)

SpaceFox commented 10 years ago

Quelques arguments contre une VM :

La taille : on fait télécharger un OS + l'intégralité de LaTeX (parce que VM de dev = VM complète)
L'utilisateur ne peut pas utiliser ses outils de développement habituels s'il en a (IDE et navigateur)
Si on veut garder une VM "légère", elle doit être sans interface graphique. Ce qui impose donc de code et commiter en mode console - si ça amuse certains OK, mais le but ici est de faire quelque chose d'accessible
Ou alors il faut monter un système compliqué de partage réseau et que l'IDE accepte d'aller chercher ça
Ou alors on fait une VM géante complète, en imposant les outils de dev (Firefox / PyCharm / SmartGit) - mais là ça devient très lourd

Au final, dans tous les cas, on a quelque chose de très lourd et pas forcément utilisable.

Pour moi, autant soigner nos procédures d'install.

Alex-D commented 10 years ago

en imposant les outils de dev (Firefox / PyCharm / SmartGit)

Huuuuuuuuuuuuuum... Non.

Je suis contre les VM, parce que c'est lourd. La VM va faire 2Go, c'est juste inconcevable. Déjà que le repo git pèse méga lourd (genre 100Mo, je trouve ça énorme). Après il faut héberger cette VM... ça bouffe un max de bande passante, etc. parce qu'il y aura probablement quelques hits dessus, mais quelques hits * 2Go, ça fait mal.

Pour moi, il faut soigner les procédures d'install.

sandhose commented 10 years ago

Vous connaissez docker ? En gros, ca permet de créer des conteneurs (je préfère ce terme à VM) Linux hyper light en fonction de l'utilisation. L'idée c'est qu'on crée un Dockerfile qui décrit l'install du conteneur, en se basant sur une base image (genre, y'a une image avec debian, ubuntu, ou juste node, python, etc... ; voir https://registry.hub.docker.com/)

L'avantage, c'est qu'on a en gros 1 fichier à rajouter (le Dockerfile), et le conteneur est prêt, suffira juste à l'utilisateur d'installer Docker, de build le conteneur (peut prendre pas mal de temps en fonction de l'image... Mais ca reste en général hyper-léger par rapport à une vrai VM), et de lancer l'app. Après, pour l'utiliser en environnement de dev, il faudrait mettre en place également fig, qui permet en fait de lancer plusieurs conteneur (un conteneur avec l'app, un avec la DB, ...), de les lier ensemble, et de "monter" le projet dans un des conteneurs, tout ça dans un fichier de config. Concrètement, il suffit que l'utilisateur installe fig + Docker, et lance "fig up" pour avoir son environnement OP, et de pouvoir modifier le code source à la volée, sans rebuild la VM

De plus, si on met en place ça pour le dev, on pourrait le réutiliser pour la prod. En effet, suffit de faire 1 conteneur pour la DB, un conteneur pour le stockage (ca implique qu'on sauvegarde toutes les données en dehors de l'app), 8 conteneurs avec l'app (multithreading, toussa toussa ; remplacerais gunicorn), et un conteneur avec Nginx, qui s'occupe du load balancing.

Tout ça pourrait rendre l'appli scalable comme il faut, puisque l'on peux configurer docker pour lie des conteneurs à travers le réseau (plusieurs serveurs, toussa toussa), et plus rapide à re-configurer.

Pour dev dans une VM avec docker depuis quelques jours, c'est vraiment agréable. Le seul bémol peut-être, est que ça marche super bien sur Linux, mais sur Windows et Mac, il faut passer par boot2docker, qui est en fait une image pour VirtualBox qui permet de lancer des conteneurs docker.

Dernier point pour la prod, si on arrive à déployer ça, il y aurais moyen de switcher sur CoreOS niveau distro, qui est en fait un linux avec juste docker, et qui est donc génial niveau perfs.

Voila, si ça vous intéresse, je peux essayer de mettre en place tout ça :)

Alex-D commented 10 years ago

Il y a Vagrant dans le même esprit non ?

SpaceFox commented 10 years ago

docker c'est LE truc qui monte, mais je ne sais pas dans quelle mesure c'est vraiment adapté à ce qu'on veut. A creuser, pourquoi pas.

2014-08-13 0:15 GMT+02:00 Alexandre Demode notifications@github.com:

Il y a Vagrant http://www.vagrantup.com/ dans le même esprit non ?

— Reply to this email directly or view it on GitHub https://github.com/zestedesavoir/zds-site/issues/1350#issuecomment-51985426 .

sandhose commented 10 years ago

A ce que je vois, l'image officielle node intègre de base python, pip, virtualenv, et la base d'Ubuntu (apt, toussa toussa)... C'est vraiment l'idéal. J'pense donc que d'ici demain je tenterais de faire un Dockerfile, et voir comment on pourrait éventuellement mettre ça en place en prod

En plus, ca a l'avantage de laisser le choix, puisque ça touche à rien au niveau de l'installation actuelle: si quelqu'un veut pas passer par Docker, il pourra toujours tout installer comme actuellement

firm1 commented 10 years ago

Des POC on veut des POC :)

Docker on y a tous pensé, mais il faut trouver un workflow qui fait rentrer Docker dans la chaine d'integration continue après le succès d'un travis, et qui héberge sur un hub les images adéquates.

Et encore, je pense que ça ne devrait pas remplacer une doc clair, Docker je le vois plutot comme un outil pour facilité la QA/préprod. Mais il n'est clairement pas pas prêt pour une production.

gasche commented 10 years ago

La page d'accueil parle de lancer les tests, mais ne donne pas la commande pour lancer des tests. Comme tout ce qui est nécessaire pour faire un petit patch, ça devrait être dans le README aussi.

gasche commented 10 years ago

Comme la documentation linux a été mise à jour, je viens de tester et "ça marche" sur ma machine -- modulo un petit changement à l'installation du virtualenv que je viens d'envoyer en PR. "Ça marche", c'est à dire que runserver crée bien un serveur local qui montre un site qui ressemble à ZdS, je n'ai pas vérifié que les outils frontend marchent.

On progresse !

sandhose commented 10 years ago

Booon, docker, ca marche plutôt bien!

J'ai fait deux tests, un avec l'install des dépendances LaTeX, et un autre sans.

En gros, avec LaTeX: 25min à build le conteneur, avec ~850Mb de téléchargement, et sans, on est à 5min, avec ~80Mb de téléchargement. (sachant que c'est à faire que la première fois, puisque docker garde une "snapshot" de chaque étape de la création du conteneur)

Les résultats en détail, avec les deux Dockerfile se trouvent sur ce gist.

Je vous invite à tester, installez docker, clonez le répo, créez un fichier "Dockerfile" avec le contenu du gist à la racine du projet, puis faites un [sudo] docker build -t zds . à la racine du projet. Pour lancer le conteneur: docker run --name zds_1 -p 8000:8000 -i --rm -t zds /usr/bin/python manage.py runserver 0.0.0.0:8000

J'aimerais bien avoir des retours la dessus (surtout par rapport au temps d'installation)

Manque plus que quelques trucs: les fixtures, et la configuration de fig

gasche commented 10 years ago

Je n'ai pas encore testé (j'essaierai à l'occasion mais j'ai dépassé mon quota de tripotage ZdS pour la journée), mais j'ai remarqué dans les logs de build Travis (celui là par exemple) qu'il passe peu de temps à installer LaTeX (il y a les timing pour chaque commande), dans les 3 minutes au total, soit moins que le pip install -r requirements.txt. Est-ce qu'ils ont trouvé l'astuce pour avoir des paquets binaires sans les sources, ou ils ont une super connexion réseau ? Il y a peut-être moyen de faire disparaître le temps lié à LaTeX.

(Et sinon distribuer une image qui n'a juste pas moyen de compiler les PDFs me semble très bien. Le temps pour se "mettre à essayer des trucs" est important pour le débutant qui essaie de contribuer pour la première fois, et 99% de ce public ne va pas s'amuser à changer la sortie PDF des tutoriels.)

sandhose commented 10 years ago

@gasche Travis a deux super pouvoirs: le cache apt, et une connexion de malade. On parle quand même de servers, alors que perso j'ai une pauvre connexion ADSL qui dépasse pas les 1.2 Mo/s

pierre-24 commented 10 years ago

Voici mon propre résultat, sur la version sans pandoc :

Commande	Temps
`apt-get docker.io`	0m35.422s
`git clone` du repo des dockerfile	0m3.404s
`git clone` de mon propre repo GH	2m1.709s
`docker build`	24m24.225s

Pour expliquer un peu ses chiffres : j'ai un pc que je pense relativement performant, mais une connexion en mousse qui tournait autour de 500Kio/s durant le processus, donc j'ai perdu un certain temps en téléchargement pur. De plus, j'ai complètement oublié de regarder ce que l'opération m'avais coûté en téléchargement, mais pour la seule partie associée à FROM dockerfile/nodejs, je compte tout de même plus de 300Mio (via ce qui était affiché par docker), il y a bien entendu toute la partie pip ... Ceci dit, d'une manière ou d'une autre, il faut télécharger tout ça quand on installe zds, je soupconne que dans ses 300Mio soient cachés tout node.js, qui auraient de touet façon dû être installé.

En conclusion de tout ça ... Et pourquoi pas ? Objectivement, la procédure automatisée est un vrai régal, on lance la commande et on attend (moi, j'ai un peu regardé ce qu'il foutait, mais on peut très bien imaginer lancer ça avant la pause de midi et avoir le truc qui soit ready).

Petite remarque, ça me fait bizarre de lancer tout ça en root, mais il semblerait qu'il y aie une solution :)

Alex-D commented 10 years ago

une connexion en mousse qui tournait autour de 500Kio/s

Dis toi que moi c'est 512kbps... soit 60kio/s donc dans tous les cas ça va me sembler lourd d'installer tout un environnement quand j'ai déjà node sur ma machine, par exemple.

Mais pour quelqu'un qui n'a rien et qui veut se lancer, ça me semble pas mal !

firm1 commented 10 years ago

Les 25Mo avec pandoc, c'est parce que tu compiles hashkell. On peut se contenter de faire comme on le fait avec travis aujourd'hui, c'est à dire télécharger la version compilée de pandoc

Et pour info travis n'utilise pas le cache chez nous, pour la simple et bonne raison que l'utilisation du cache est payant

GerardPaligot commented 10 years ago

Je relance cette issue parce que docker semble une techno super intéressante et apporterait beaucoup à ZdS (imaginez une documentation allégée à une simple explication de docker et plus sur tous les OS !)

SpaceFox commented 10 years ago

Certes, mais docker pose aussi des problèmes (il me semble déjà mentionnés ci-dessus) que l'on doit résoudre.

Le 10 octobre 2014 09:36, Gerard notifications@github.com a écrit :

Je relance cette issue parce que docker semble une techno super intéressante et apporterait beaucoup à ZdS (imaginez une documentation allégée à une simple explication de docker et plus sur tous les OS !)

— Reply to this email directly or view it on GitHub https://github.com/zestedesavoir/zds-site/issues/1350#issuecomment-58621989 .

GerardPaligot commented 10 years ago

Je parcourus l'issue et le seul problème que je relève c'est par firm1 avec pandoc où il donne une solution dans la foulée.

SpaceFox commented 10 years ago

C'est pas ici qu'on avait parlé de la taille du truc, du temps de téléchargement et des mises à jour ??

GerardPaligot commented 10 years ago

Si, si mais je ne comptais pas vraiment ça comme un problème vu le temps que prend un nouveau contributeur a initialiser le projet et la taille des choses téléchargées pour cette installation.

Alex-D commented 10 years ago

Docker = VM ? Si oui, VM = 1Go à télécharger = je ne peux plus contribuer ou alors je dois laisser tourner ma machine un ou deux jour non-stop pour avoir un environnement de travail. A moins que ça pèse moins que ça (ça se peut), quelqu'un aurait une estimation ?

Eskimon commented 10 years ago

Si docker est utilisé rien ne t'obligeras à l'utiliser hein.

Alex-D commented 10 years ago

@GerardPaligot sous-entend qu'il n'y aurait plus à maintenir la documentation sur les 3 OS, ce qui sous-entend que je n'aurais plus de support pour installer tout ça sur mes machines.

GerardPaligot commented 10 years ago

Docker se base sur des conteneurs et pas des vm. C'est important parce que justement, docker en soit ne pèse rien. Sur Linux, docker est supporté nativement, à partir d'une contribution en loose D par Google dans le noyau Linux il y a quelques années.

Pour Mac et Windows, oui ce n'est pas supporté nativement. Donc oui, c'est une VM mais extrêmement légère (quelques Mo). Il n'y a vraiment aucun problème sur ce point.

Si vous voulez plus de détails sur le sujet sans vous tapez la documentation, il y a eu une session organisée par le Chti JUG sur docker disponible depuis leur site.

Alex-D commented 10 years ago

Donc oui, c'est une VM mais extrêmement légère (quelques Mo).

Ca me va dans ce cas :)

SpaceFox commented 9 years ago

Ah ben ça c'est la discussion de tout à l'heure sur IRC. À noter que le titre est obsolète, on met déjà moins de 30 min. Mais je laisse ouvert pour les idées d'amélioration.

GerardPaligot commented 8 years ago

@SpaceFox Tu veux vraiment garder cette issue ouverte ? Elle n'est pas visible et elle n'est là que pour des potentielles nouvelles idées.

gustavi commented 8 years ago

J'ai envie de dire : si quelqu'un prend du courage et arrive à installer une version de prod en moins de 30 minutes grâce à la doc cette issue peut être fermée. Dans le cas contraire il faut voir ce qu'on peut faire pour améliorer le process.

gasche commented 8 years ago

J'ai une nouvelle machine sans rien de frontend web installé, je peux essayer de faire un test ce week-end. N'hésitez pas à pinger si j'oublie.

GerardPaligot commented 8 years ago

@gasche Je te reping lundi si tu as oublié. :)

gasche commented 8 years ago

Donc bon je viens de faire un essai, ce n'est pas complètement satisfaisant: en tout pile 30 minutes j'ai réussi à aller jusqu'à la commande npm run gulp build, qui échoue. Voici le log avec toutes les notes que j'ai prises.

## Installation des dépendances
## Temps de cette partie: 9 minutes

# Je suis sous Fedora donc j'ai du adapter les noms de paquet. C'était
# globalement simple, sauf pour "libz" comme précisé ci-dessous. Ce
# serait sympa d'indiquer aussi les noms de paquets Fedora (en
# commentaires par exemple) dans la doc d'installation. Ci-dessous
# j'ai mis les commandes complètes que j'ai utilisées.

sudo dnf install python2
sudo dnf install python-setuptools

# on dirait que par défaut Fedora configure easy_install/pip pour
# installer dans l'espace root, donc j'ai besoin de "sudo" pour que
# les commandes ci-dessous marchent
sudo easy_install pip
sudo pip install tox

sudo dnf install libxml2-devel
sudo dnf install libxslt-devel libxslt-python

# il y a plein de paquets en "libz" (libzdb, libzip, libzen...),
# préciser dans la doc que c'est bien libzip serait utile -- j'ai
# cherché la description du paquet Ubuntu pour deviner
sudo dnf install libzip-devel

# la doc est peu claire: "python-sqlparse", install pip ou package manager?
sudo pip install sqlparse

sudo dnf install libffi-devel

sudo dnf install libjpeg-turbo-devel freetype-devel

# Ah ben en-dessous il y a la méthode "en une ligne", mais comme elle
# est en dessous je ne l'avais pas vue. La mettre au dessus ?

## Installation des backend et frontend proprement dits
## Temps jusqu'à la fin du fichier: 21 minutes

pip install --user virtualenv 
virtualenv zdsenv --python=python2
# est-ce que j'aurais dû créer un répertoire zds avant de lancer cette dernière commande ?

# Je suis toujours sur
# http://zds-site.readthedocs.org/fr/latest/install/backend-linux-install.html
# et il n'y a aucune indication sur comment cloner le code source. Je
# sais que c'est censé être évident, mais si c'est une doc à suivre
# étape par étape vous pourriez donner la commande pour cloner au bon
# moment, et préciser quand vous donnez des commandes comme
#   pip install --upgrade -r requirements.txt -r requirements-dev.txt
# qu'on est censé être dans le repo du projet

# Du coup je suppose qu'il faut faire
git clone git@github.com:zestedesavoir/zds-site.git

# Pendant que ça clone j'installe les outils du frontend
#   http://zds-site.readthedocs.org/fr/latest/install/frontend-install.html
sudo dnf install nodejs

# la doc semble oublier de préciser qu'il faut install npm aussi (sur
# Fedora c'est un paquet séparé) donc je rajoute moi-même (sinon la
# ligne `npm install -g npm` ne peut pas marcher) la commande
# suivante:
sudo dnf install npm

sudo npm install -g npm

# Le dépôt git est cloné, je retourne au backend

cd zds-site # pas précisé dans la doc
virtualenv zdsenv --python=python2
source zdsenv/bin/activate
pip install --upgrade -r requirements.txt -r requirements-dev.txt

# ça prend un moment, je repars sur le frontend

# les versions sont plus récentes que celles indiquées dans la doc, j'imagine que c'est bon:
#    $ node -v
#    v0.10.36
#    $ npm -v
#    3.7.2

npm install

# ça prend un moment, on repasse au frontend
python manage.py migrate
python manage.py runserver

# Pas d'info dans la doc d'installation sur quelle URL utiliser pour
# se connecter au serveur qu'on vient de lancer. Vous devriez au moins
# dire que c'est indiqué dans le message de runserver. Par ailleurs je
# viens d'essayer et ça foire, ça doit être que le frontend n'est pas
# complètement installé encore.

# Message d'erreur:
#    OSError at /
#    [Errno 2] No such file or directory: '/tmp/zds/zds-site/dist'

# Pendant ce temps l'install du frontend crache pas mal de warnings. Des mises à jour à faire ?
#   npm WARN deprecated lodash@1.0.2: lodash@<3.0.0 is no longer maintained. Upgrade to lodash@^4.0.0.
#   npm WARN deprecated npmconf@2.1.2: this package has been reintegrated into npm and is now out of date with respect to npm
#   npm WARN deprecated lodash.padright@3.1.1: This package has been renamed. Use lodash.padend@^4.0.0.
#   npm WARN deprecated lodash-node@2.4.1: This package has been discontinued in favor of lodash@^4.0.0.
#   npm WARN deprecated lodash@2.4.2: lodash@<3.0.0 is no longer maintained. Upgrade to lodash@^4.0.0.
#   npm WARN prefer global marked@0.3.5 should be installed with -g
#   npm WARN prefer global jshint@2.9.1 should be installed with -g
#   npm WARN prefer global node-gyp@3.2.1 should be installed with -g

# Le `npm install` est terminé, on continue sur le frontend

npm run gulp build

# gulp build échoue. Le message d'erreur contient en particulier:

# [10:30:30] Starting 'stylesheet'...
# 
# /tmp/zds/zds-site/node_modules/postcss/lib/lazy-result.js:157
#         this.processing = new Promise(function (resolve, reject) {
#                               ^
# ReferenceError: Promise is not defined
#     at LazyResult.async (/tmp/zds/zds-site/node_modules/postcss/lib/lazy-result.js:157:31)
#     at LazyResult.then (/tmp/zds/zds-site/node_modules/postcss/lib/lazy-result.js:79:21)
#     at Transform.stream._transform (/tmp/zds/zds-site/node_modules/gulp-postcss/index.js:45:8)
#     at Transform._read (_stream_transform.js:179:10)
#     at Transform._write (_stream_transform.js:167:12)
#     at doWrite (_stream_writable.js:226:10)
#     at writeOrBuffer (_stream_writable.js:216:5)
#     at Transform.Writable.write (_stream_writable.js:183:11)
#     at write (/tmp/zds/zds-site/node_modules/gulp-sass/node_modules/readable-stream/lib/_stream_readable.js:623:24)
#     at flow (/tmp/zds/zds-site/node_modules/gulp-sass/node_modules/readable-stream/lib/_stream_readable.js:632:7)
#     at DestroyableTransform.pipeOnReadable (/tmp/zds/zds-site/node_modules/gulp-sass/node_modules/readable-stream/lib/_stream_readable.js:664:5)
#     at DestroyableTransform.emit (events.js:92:17)
#     at emitReadable_ (/tmp/zds/zds-site/node_modules/gulp-sass/node_modules/readable-stream/lib/_stream_readable.js:448:10)
#     at emitReadable (/tmp/zds/zds-site/node_modules/gulp-sass/node_modules/readable-stream/lib/_stream_readable.js:444:5)
#     at readableAddChunk (/tmp/zds/zds-site/node_modules/gulp-sass/node_modules/readable-stream/lib/_stream_readable.js:187:9)
#     at DestroyableTransform.Readable.push (/tmp/zds/zds-site/node_modules/gulp-sass/node_modules/readable-stream/lib/_stream_readable.js:149:10)

# et le npm-debug.log est le suivant

# 0 info it worked if it ends with ok
# 1 verbose cli [ 'node', '/usr/bin/npm', 'run', 'gulp', 'build' ]
# 2 info using npm@3.7.2
# 3 info using node@v0.10.36
# 4 verbose run-script [ 'pregulp', 'gulp', 'postgulp' ]
# 5 info lifecycle zds-site@0.2.0~pregulp: zds-site@0.2.0
# 6 silly lifecycle zds-site@0.2.0~pregulp: no script for pregulp, continuing
# 7 info lifecycle zds-site@0.2.0~gulp: zds-site@0.2.0
# 8 verbose lifecycle zds-site@0.2.0~gulp: unsafe-perm in lifecycle true
# 9 verbose lifecycle zds-site@0.2.0~gulp: PATH: /usr/lib/node_modules/npm/bin/node-gyp-bin:/tmp/zds/zds-site/node_modules/.bin:/usr/bin:/tmp/zds/zds-site/zdsenv/bin:/home/gasche/.opam/4.02.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/gasche/.local/bin:/home/gasche/bin
# 10 verbose lifecycle zds-site@0.2.0~gulp: CWD: /tmp/zds/zds-site
# 11 silly lifecycle zds-site@0.2.0~gulp: Args: [ '-c', 'gulp "build"' ]
# 12 silly lifecycle zds-site@0.2.0~gulp: Returned: code: 8  signal: null
# 13 info lifecycle zds-site@0.2.0~gulp: Failed to exec gulp script
# 14 verbose stack Error: zds-site@0.2.0 gulp: `gulp "build"`
# 14 verbose stack Exit status 8
# 14 verbose stack     at EventEmitter.<anonymous> (/usr/lib/node_modules/npm/lib/utils/lifecycle.js:239:16)
# 14 verbose stack     at EventEmitter.emit (events.js:98:17)
# 14 verbose stack     at ChildProcess.<anonymous> (/usr/lib/node_modules/npm/lib/utils/spawn.js:24:14)
# 14 verbose stack     at ChildProcess.emit (events.js:98:17)
# 14 verbose stack     at maybeClose (child_process.js:766:16)
# 14 verbose stack     at Process.ChildProcess._handle.onexit (child_process.js:833:5)
# 15 verbose pkgid zds-site@0.2.0
# 16 verbose cwd /tmp/zds/zds-site
# 17 error Linux 4.2.5-300.fc23.x86_64
# 18 error argv "node" "/usr/bin/npm" "run" "gulp" "build"
# 19 error node v0.10.36
# 20 error npm  v3.7.2
# 21 error code ELIFECYCLE
# 22 error zds-site@0.2.0 gulp: `gulp "build"`
# 22 error Exit status 8
# 23 error Failed at the zds-site@0.2.0 gulp script 'gulp "build"'.
# 23 error Make sure you have the latest version of node.js and npm installed.
# 23 error If you do, this is most likely a problem with the zds-site package,
# 23 error not with npm itself.
# 23 error Tell the author that this fails on your system:
# 23 error     gulp "build"
# 23 error You can get information on how to open an issue for this project with:
# 23 error     npm bugs zds-site
# 23 error Or if that isn't available, you can get their info via:
# 23 error     npm owner ls zds-site
# 23 error There is likely additional logging output above.
# 24 verbose exit [ 1, true ]

gasche commented 8 years ago

Je crois que cet essai démontre que:

Il y a des problèmes actuels d'incompatibilités entre certaines versions de vos dépendances à corriger, et du coup ça ne marche pas chez moi. Ça c'est un peu la vie, je ne critique pas particulièrement.
Les instructions d'installation sont nettement améliorables (cf. les questions que je me suis posées pendant mon installation, notées dans mes logs; en particulier vous ne dites jamais clairement à quel moment cloner les sources du dépôt, et comment aller sur le site lancé en local).
Il n'y a pas de vrais débutants qui testent vos instructions d'installation régulièrement. Si c'était le cas, (1) serait peut-être réglé et (2) aurait forcément été révélé comme un problème précédemment. À mon avis c'est ça le vrai problème. Vous devriez organiser un truc sur le forum pour encourager les gens à builder le site en local et essayer de faire leur première contribution.
En conséquence, les contributeurs réguliers ont une vision faussée de la facilité de contribuer au projet. Cf. le message un peu à côté de la plaque de @Eskimon dans #6 : « Bon, vu que la doc' d'install est suffisamment complète, je ferme ce ticket obsolète. ». Nope.

SpaceFox commented 8 years ago

Il faudrait mettre à jour les dépendances pour les versions récentes de Linux. À noter qu'a ma connaissance, personne n'avait essayé avec Fedora.
Complètement d'accord.
Qu'appelles-tu « vrai débutant » ? « Débutant » au sens de ZdS ou au sens du développement Django ? Parce que dans le second cas, cette personne ne pourra pas faire grand-chose pour le développement, cette personne aura de toutes façons besoin d'aide pour contribuer.
Le message d'Eskimon était peut-être vrai au moment où il l'a écrit, c'est le genre de chose qui change (en particulier npm, qui ne posait plus aucun problème jusqu'à quelques mois).

sandhose commented 8 years ago

Pour ce qui est de node, c'est entièrement de ma faute, puisque j'ai mis à jour à un moment certaines dépendances qui rendaient le stack incompatible avec node<0.12, sans pour autant mettre à jour les instructions d'installation dans la doc (qui fait installer la version 0.10 la plupart du temps). @Situphen a fait une PR qui met à jour la doc d'install, en demandant d'installer la v4.x de node: #3370

gasche commented 8 years ago

J'entends par débutant quiconque a une expérience modique de la programmation et voudrait essayer de faire un changement au site par lui-même ou elle-même. Prenez le commit 31c0634e6712b0599118eb43cc3276f99ee0d505 par exemple; n'importe qui utilise le site pourrait se dire "ah bah tiens, il manque un mot, je vais le rajouter dans le code source, ça doit être facile". N'importe qui sait utiliser grep (ou encore mieux, git grep) peut trouver en 10 secondes où est le code source à modifier. Mais ensuite la personne veut tester son changement en local... et là ça coince.

Je ne suis pas trop convaincu par ton idée de "de toute façon si la personne ne connaît pas Django, elle ne pourra pas contribuer". Dans tous les cas, "essayer de lancer le site en local" c'est l'étape 0 pour toute contribution; même si les gens ont besoin d'aide ensuite, il faut qu'ils puissent faire cette première étape par eux-mêmes, sinon ça peut les décourager de contribuer.

@sandhose pas de soucis, tenez-moi au courant quand les instructions seront à jour, je referai une tentative.

SpaceFox commented 8 years ago

Là on est d'accord qu'il y a un problème. Je posais la question parce que y'a quelque temps, il y avait un débat avec des personnes qui voulaient permettre à absolument n'importe qui de pouvoir contribuer… ce qui n'est hélas pas possible vue la complexité du projet.

gasche commented 8 years ago

@sandhose à y re-réfléchir, je me demande comment ça se fait qu'aucune des commandes que j'ai lancées ne m'ait dit à un moment "ta version de node est trop vieille". C'est bien de le documenter dans les infos d'installation mais je me serais attendu à un test en dur d'une borne de dépendance, plutôt qu'une erreur bizarre sur Promise qui n'existe pas (impossible à analyser pour un non-spécialiste). Dans ma communauté, avoir une étape de ./configure qui teste ces trucs là et produit une erreur compréhensible est la norme; est-ce qu'il n'y a pas un équivalent pour les frontend nodejs qui pourrait être intégré aux instructions d'installation ?

zestedesavoir / zds-site

Rendre ZdS installable en 30 minutes #1350