J'arrive pas à faire tourner docker sur mon mac !

J'ai pas réussi avec homebrew (un apt-get like), donc j'ai installé l'officiel du site officiel, mais la seule chose qu'il me fait c'est me hurler des insultes, plus ou moins verboses suivant que je le lance avec -v ou pas ! :)

Je rééssaierai plus tard, là back2taff !

Le boot2docker "officiel" qui :
- lance une nouvelle fenêtre de terminal alors qu'il pourrai détecter que j'en ai déjà une ouverte avec des onglets
- lance une nouvelle fenêtre sous bash alors que mon $SHELL est != de bash
- lance une nouvelle fenêtre sous bash SANS passer via le .bashrc ou le .bash_profile du user, donc sans ses alias et personnalisations
Pour tout ça : die in a fire ! Si j'utilise un outil en ligne de commandes, c'est que je sais l'utiliser, c'est que je l'utilise !

TchouGlobalement, j'ai pensé à un truc peut être infaisable, mais je lance le concept con (en sachant que je ne suis pas forcément client de mon idée, donc prenez ça avec des pincettes.) : est-il possible en l'état de pusher le minichat dans une appli de notification, ce genre d'appli qui ont poussé depuis peu sur tous les OS ? Ce serai une interface différente d'accès à l'information, suppl´mentaire, et je ne sais même pas si c'est faisable et si j'utiliserai, c'est dire si je ne m'avance pas !

Je ne suis pas sûr de bien comprendre

Tchou"est-ce qu'il n'existe pas mieux ?".

Pour le CSS du Lexpage, le gros souci, c'est que je n'ai pas créé un "thème" via LESS (par exemple), mais j'ai simplement écrit des règles CSS qui viennent remplacer le comportement de Bootstrap. Le "hic", c'est qu'en cas de mise à jour de Bootstrap, il y a fort à parier que tout parte en vrille...

J'ai un peu de mal à voir comment "thêmer" proprement Bootstrap, et vu les nombreux sujets en rapport avec ça sur le net, je pense que je suis loin d'être le seul

De ce que j'avais pu voir en faisant d'autres essais avec Bootstrap pour d'autres projets, c'est qu'il est sans doute bien plus facile d'écrire un jeu de règles supplémentaires directement dans le LESS de Boostrap et de générer un "Bootstrap-Lexpage" contenant à la fois le jeu de règles de base de Boostrap + les spécificités du site.

Actuellement, j'inclus :
- bootstrap.css --> la base de bootstrap
- lexpage-bootstrap.css --> un clone de bootstrap.css dans lequel j'ai fait des modifications propres à Lexpage. Normalement, bootstrap.css ne devrait plus être nécessaire, j'imagine. L'idée ce serait d'avoir soit ce fichier généré automatiquement via LESS (ou SASS ou autre), soit qu'il ne contienne que le delta à appliquer au dessus de bootstrap.css
- lexpage.css -> contient les éléments CSS du Lexpage qui ne sont pas liés à Bootstrap (par ex, les billets, le forum, les notifications, etc.)

TchouJe veux bien me charger de cette partie-là, mais tu seras le mainteneur final, donc ça mérite quand même que tu donnes ton avis.

C'est difficile, parce que mon expérience dans ce domaine est très limitée. Je sais juste qu'actuellement, il m'est TRÈS difficile d'envisager de faire une "skin" pour Lexpage, tout simplement parce que je n'ai aucun moyen facile de distinguer automatiquement ce qui fait partie de Boostrap et ce qui fait partie du "thème Lexpage".

pomHum ? Je connais pas ces 2 outils Python en fait. Quel avantage par rapport à Docker qui virtualise déjà un
environnement? Et tant que j'y suis, que t'apporte gunicorn ou wUSGI ? Ça a un rapport avec OSGI, l'architecture de services sur laquelle est construit Eclipse?

Docker te virtualise un environnement complet (avec des images de plusieurs centaines de mo). Virtualenv et Pew vont juste changer localement les variables d'environnement pour que les appels à Python se fasse sur un binaire local, et que les librairies soient aussi installées/chargées localement. En général, ça se traduit par environ 50mo contenant les binaires Python, pip et les librairies installées.

uWSGI et Gunicorn, ce sont deux serveurs WSGI, une norme Python pour, grosso-modo, "transformer une requête HTTP en objet Python et transformer une réponse Python en message HTTP". Il y a d'autres alternatives, mais ce sont les deux meilleures en terme de souplesse et de performances. Ils sont tellement performants qu'on peut directement l'utiliser en frontal si on le souhaite. En gros, gunicorn ou uwsgi te permet de lancer un "serveur web qui comprend le Python".

pomBen c'est pas la commande elle-même qui précise le volume et donc le chemin physique?

Dans le monde parfait des vrais linuxiens, si. Mais chez les hérétiques qui travaillent sur Mac, non : Docker tourne dans une machine virtuelle, et donc le chemin que tu précises quand tu fais un docker run, il est relatif au filesystem de la VM, pas au filesystem de ton système. Il est donc nécessaire, si tu souhaites copier un fichier ou monter un volume, de rendre ce fichier ou ce volume disponible dans ta VM. C'est sans doute la raison pour laquelle ton "HelloWorld" fonctionne (il ne copie/monte rien) et pas le reste.

pom"Détail en passant, mais à mon avis tu devrais davantage coller à la convention concernant le tag de ton build Docker, et plutôt que Lexpage/dev préférer Lexpage:dev.".

Justement, la convention est d'utiliser "lexpage/dev" et pas "lexpage:dev" (j'ai changé le readme ce matin).

@Tchou : le fichier .bashrc est reconnu par la fenêtre lancé par boot2docker (mais pas .bash_profile).
Ensuite, j'ai pas eu trop de problème pour lancer un premier docker run.

Ce qui m'a fait rigoler de mon côté, c'est lors de l'install de git. L'ordi détecte qu'on veut installer un truc de développeur et propose d'installer Xcode pour cela, bref un téléchargement de pas loin de 3 Go. À la place tu tapes :

alias git="/usr/local/git/bin/git"

Et la commande git est opérationnelle dans la foulée. Autrement plus simple!

@Guy : Oui, lexpage/dev c'est mieux. Ma phrase (reformulée) voulait dire l'inverse, désolé!

GuybrushJe ne suis pas sûr de bien comprendre

En gros, je lance en l'air le fait d'utiliser les notifications sur les bureaux modernes pour afficher le minichat. Je suis même pas certain que ça soit possible, si ça l'est, ce sera via xmpp je dirai.

Actuellement, j'inclus :
- bootstrap.css --> la base de bootstrap
- lexpage-bootstrap.css --> un clone de bootstrap.css dans lequel j'ai fait des modifications propres à Lexpage. Normalement, bootstrap.css ne devrait plus être nécessaire, j'imagine. L'idée ce serait d'avoir soit ce fichier généré automatiquement via LESS (ou SASS ou autre), soit qu'il ne contienne que le delta à appliquer au dessus de bootstrap.css
- lexpage.css -> contient les éléments CSS du Lexpage qui ne sont pas liés à Bootstrap (par ex, les billets, le forum, les notifications, etc.)

Un truc du style :
bootstrap.scss qui contient un boostrap "à jour"
lexpage.scss qui contient un import du bootstrap + les ajouts spécifiques :

$couleurDeFond = '#123456';
@import "bootstrap"
(les customisations lexpage)

Et à la fin, tu génère un .css tout ce qu'il y a de plus standard, voire un css compacté.

Tu veux générer une skin spécifique pour la st valentin ? Si tu as bien prévu le coup, en changeant une variable tu change déjà pas mal de choses dans ton interface. Par exemple, ton bleu "couleur du bandeau" tu l'affecte à une variable, et c'est la même que la couleur du bouton. En une variable tu change le tout. et ce serai dommage de s'arrêter là : la couleur du bloc bleu plus clair, c'est un lighten à 30% de ta couleur générale par exemple.

Et pof, en un "compass compile" et un changement de variable, dans un monde idéal on change toute la couleur du site.

Le gros avantage de cette techno, c'est la facilité pour la maintenance : avoir une CSS pour chaque élément de la page (footer, header, titres, listes, liens) serai un non-sens en terme de performances, mais super utile pour la maintenance. Là, tu peux avoir 20 fichiers très spécialisés, hop un coup d' @import, en une ligne de commande tu génère ton fichier final qui supprime les espaces en trop, les commentaires, et qui a concat tout. Best of both worlds !

pom@Tchou : le fichier .bashrc est reconnu par la fenêtre lancé par boot2docker (mais pas .bash_profile).

Effectivement, j'ai dit une connerie, j'étais persuadé d'avoir un bashrc, je n'avais qu'un bash_profile, mais avant de switcher sous zsh (y'a un bail) ce fichier était fonctionnel.

Par contre, docker ne marche pas du tout pour moi, même le hello world. J'ai ce bug-là et aucune solution n'a fonctionné.

pomCe qui m'a fait rigoler de mon côté, c'est lors de l'install de git. L'ordi détecte qu'on veut installer un truc de développeur et propose d'installer Xcode pour cela, bref un téléchargement de pas loin de 3 Go. À la place tu tapes :

alias git="/usr/local/git/bin/git"

Genre ils pouvaient pas essayer un whereis git avant et voir s'il y avait un résultat ? Si ton bashrc avait bien été parsé, il n'avait pas déjà l'alias ?

TchouSi tu as bien prévu le coup, en changeant une variable tu change déjà pas mal de choses dans ton interface.

Ce n'est pas le cas actuellement, mais c'est un objectif à atteindre

Bon, je vais déjà commencer par réorganiser un peu les fichiers statiques ("subdirectoré" les CSS, JS, etc. et résoudre le "problème" des avatars qui se font trasher en prod dès que je fais un django clean )

Je veux bien me charger de la branche "SASSisons la lexpage". Il y aura "juste" un prérecquis supplémentaire sous la forme d'un besoin de compilation de la CSS, mais si ça te va, je me charge de ça.

Comme indiqué, je connais compass, mais je vais voir si ses alternatives sont plus vivaces, car la doc de compass sur son site est à pleurer ( compass-style.org/ car rechercher compass sur un moteur de recherche c'est un peu compliqué)

Pas de souci, je suis preneur

Je regarde du coté de django-pipeline qui permet d'adjoindre un traitement lors de la collecte des fichiers statiques, mais je pense que je vais gérer ça "à la main", quitte à faire un Grunt ou Gulp par la suite.

TchouGenre ils pouvaient pas essayer un whereis git avant et voir s'il y avait un résultat ? Si ton bashrc avait bien été parsé, il n'avait pas déjà l'alias ?

Le .bashrc n'existait pas, je l'ai fait à la main et j'ai ajouté l'alias à l'intérieur.

J'ai fait un peu le tour des solutions pour intégrer des websockets, et y a rien de bien folichon en réalité. La meilleure approche semble être de développer une petite application serveur classique (qui peut éventuellement faire appel à quelques routines Django, par exemple pour graber les données, etc.). En fait, ce n'est pas étonnant, vu que finalement, les websockets offrent juste la possibilité de faire des apps réseaux "classiques" via le web HTTP...

Par contre, pour faire du "push" de masses, j'hésite encore à sortir des artilleries comme RabbitMQP (crossbar.io est encore un peu jeune pour ça) ou à bricoler quelque chose sur du Redis (ou à bricoler quelque chose via autre chose ).

GuybrushPar contre, pour faire du "push" de masses, j'hésite encore à sortir des artilleries comme RabbitMQP (crossbar.io est encore un peu jeune pour ça) ou à bricoler quelque chose sur du Redis (ou à bricoler quelque chose via autre chose ).

Redis++

Tu pourras t'en servir comme cache applicatif, ça résouds tous les problèmes ce truc, j'adore.