Re: [openplacos-dev] integration

Le 29 avril 2012 08:17, jay peche <jaypeche@xxxxxxxxx> a écrit :

Je pense que le Gemfile.lock que tu as dans ton repo local a été
généré lors d'un # bundle install .

Exact, je n'avais pas fait attention à cela !

Pour donner mon avis je trouve que le bundle ne peut apporter que du bon, ca permet de gérer les gems facilement( sauf gemfile en git peut etre). Chez moi bundler à toujours très bien fonctionné hormis peut etre oauth (git).

.1. en dev, on fait du bundle install pour tester des Gemfile.lock. Une

fois qu'on en est content ben c'est cool
2. lors de la generation de paquets, on part de ce Gemfile.lock pour
cacher dans le paquet tous les gems.
3. a l'install, les users installent les gems en local a partir des
paquets caches dans le paquet.

Je suis pas assez au top, donc a voir avec le Kirsh, mais cette solution devrait permettre d'etre sur que le bundler installe bien les gems appropriées à chaque version d'opos, comme ça à chaud je trouve que c'est pas mal.

Cet outil (Gemfile) est vraiment bien à mon sens car il permet de se bloquer sur des versions dont on est sur tout en gérant les dépendances.

Le 28 avril 2012 10:35, flagos <flagospub@xxxxxxxxx> a écrit :

Chez moi Gemfile et Gemfile.lock sont rapatriés en git

Pour Gemfile, oui je suis dacc. Par contre, le Gemfile.lock, lui n'est
pas present dans git. Un petit tour sur le repo pour confirmer la
chose:
https://github.com/openplacos/openplacos/tree/integration

Je pense que le Gemfile.lock que tu as dans ton repo local a été
généré lors d'un # bundle install . Ce Gemfile.lock est generé avec
les versions exactes qui ont été matches selon les contraintes
decrites dans le Gemfile et ce qui était disponible sur rubygems.org.

Je vais refaire un petit point sur ce que j'ai compris des Gemfile,
comment on souhaite s'en servir, et ce que ton ton retour d'experience
nous a montré.

Le Gemfile.lock est alors une entrée nécéssaire de #bundle install
--deployment qui s'en sert pour choper les versions exactes et les
installer en local. Ca te fait un flow en 2 étapes:

- Les developpeurs font des bundle install pour choper leur gem et
generer un Gemfile.lock. Cet environnement sera testé par les
developpeurs. Une fois le dev terminé, le .lock fait parti integrante
des sources. => #bundle install fait par les devs
- A l'install, les scripts d'install des distribs récupèrent le .lock,
font une install en local des gems, et surtout, cherchent a reproduire
l'environnement exact de développement pour éviter les blagues. =>
#bundle install --deployment fait par les users

Pour avoir tester chez moi bundle --deployment chez oim, je pense que
si il faut l'intégrer à présent ca pose pas de souçi particuliers

Super. En fait, tu as eu un souci qui nous a un peu tracassé. Tu avais
géngéré un Gemfile.lock en faisant un #bundle install et 2 jours
apres, tu avais tenté un #bundle install --deployment. Entretemps, il
y avait un paquet selectionné dans Gemfile.lock qui avait disparu,
déclaré non stable, ce qui t'avait laché une erreur au moment du
--deployment. On ne savait pas qu'il y avait cette possibilité de
faire disparaitre une version d'un paquet sur rubygems. C'est vraiment
emmerdant parce que ca fait que du jour au lendemain, une version
stable d'opos peut ne plus s'installer a cause d'une envie soudaine
d'un dev qui maintient son paquet de ne plus supporter cette version.

Du coup on a cherché avec le kirsh, et on a trouvé ce truc de bundle:
http://gembundler.com/bundle_package.html . Il s'agit de garder une
copie locale des gems utilisées au sein des sources du projet. Plutot
que de generer un .lock qui contiendrait les versions a aller chercher
sur rubygems, on garde une copie des paquets, comme ca pas de blagues,
ils disparaitront pas.

Par contre, et la dessus j'aimerais avoir ton avis, on veut pas
s'amuser a traquer sous git tous les gems qu'on utilise. Du coup, avec
le kirsh on s'etait qu'une solution pas mal ce serait:
1. en dev, on fait du bundle install pour tester des Gemfile.lock. Une
fois qu'on en est content ben c'est cool
2. lors de la generation de paquets, on part de ce Gemfile.lock pour
cacher dans le paquet tous les gems.
3. a l'install, les users installent les gems en local a partir des
paquets caches dans le paquet.

Ca nous permet de pas avoir a gerer dans la db git toutes sortes de
gems, mais pour autant d'avoir la reproductibilité et fiabilité a
l'install chez les users.

Ca, ca marche bien sur les distrib qui sont en mode paquet binaire.
Pour les distribs qui sont en mode paquet source (gentoo et arch
principalement), elles vont direct chercher sur le repo, le coup du
cache dans le paquet de la distrib ne tient plus. Comment faire dans
ce cas la ? La petite idée que j'en ai serait que lorsqu'on release
une version stable, on cree un .tar.gz qui contient les sources + tous
les paquets cachés: ca permet de garantir que la version stable l'est
vraiment tandis qu'en unstable, et ben la effectivement on tape sur le
repo github, donc des fois ca peut bugguer, c'est normal.

Est ce que ca vous parait raisonnable comme maniere de faire ? Vous y
voyez des inconvenients ?

Le 28 avril 2012 02:38, jay peche <jaypeche@xxxxxxxxx> a écrit :

> Chez moi Gemfile et Gemfile.lock sont rapatriés en git et bundle
> --deployment n'est pas utile sur le dernier commit de la V3.0. Pour avoir
> tester chez moi bundle --deployment chez oim, je pense que si il faut
> l'intégrer à présent ca pose pas de souçi particuliers; voila ..
>
>
> Le 26 avril 2012 23:48, flagos <flagospub@xxxxxxxxx> a écrit :
>
>> Yop,
>>
>> Suite aux soucis rencontres par Jay il y 2-3 semaines, j'ai tenté moi
>> meme d'installer un opos a partir de la branche unstable.
>> Effectivement, il y avait 2-3 choses fun ;-). J'ai fait tout un tas de
>> commits sur la branche integration pour gerer les soucis. Cette
>> branche est dédiée aux questions d'integration. Lorsque tout le monde
>> sera satisfait de cette branche, on la mergera dans unstable.
>>
>> Voici les étapes que j'ai eu a faire pour faire une install sur
>> ubuntu12.04:
>>
>> cd <repo>
>> apt-get install ruby1.9.1 ruby1.9.1-dev dbus g++ libsqlite3-dev
>>
>> make install
>> cd /usr/lib/ruby/openplacos
>>
>> gem1.9.1 install bundle
>> bundle install # juste pour generer Gemfile.lock --> inutile de le
>> scripter Gemfile.lock sera genere dans la branche master
>> bundle install --deployment
>>
>> adduser openplacos # voir dans les scripts debian pour la commande
>> complete
>> /etc/init.d/openplacos start
>>
>> Et normalement, je dis bien normalement, ca devrait marcher.
>>
>> --
>> Tapé depuis mon clavier
>>
>>
>

--
Tapé depuis mon clavier