[SPIP Zone] Référencer un plugin développé sur github sur plugins.spip.net

cerdic · Mars 5, 2014, 9:36

Hello,

c'est encore experimental, et il est possible que certaines choses ne marchent pas très bien,
mais il devient possible de référencer un plugin développé sur github sur plugins.spip.net

Pour cela, il faut le référencer en externals dans le dossier _externals_ de la zone, en utilisant l'URL de checkout SVN fournie par github.

En ligne de commande cela donne :

$ cd spip-zone
$ svn up --ignore-externals _externals_
$ cd _externals_
$ svn propedit svn:externals .

Là dans votre éditeur, ajoutez la ligne pour indiquer à SVN le nom du dossier du checkout et l'URL SVN du repository Github.

Par exemple :

video_accessible https://github.com/Cerdic/video_accessible

Enregistrez, et commitez :

$ svn commit . -m"Ajout de video_accessible aux externals"

Pour voir si le checkout va bien fonctionner il suffit de faire

$ svn up .

SVN va alors aller chercher le repository https://github.com/Cerdic/video_accessible et le checkout dans le dossier video_accessible

Il suffit ensuite de l'ajouter a archivelist.txt :

_externals_/video_accessible/tags/v0.6.8/;video_accessible

Important : le checkout du repository Github ne sera pas automatiquement mis à jour en fonction des commit de github, donc inutile de générer un zip depuis le trunk il ne sera jamais à jour.

Il convient absolument d'utiliser un tag pour générer le zip, et de venir mettre à jour le archivelist quand c'est necessaire. C'est un peu plus lourd, mais pour le moment c'est le mieux qu'on puisse faire sans se retrouver avec une génération de zip qui prenne des heures.

Enjoy !

NB : cela ne permettra pas de contribuer depuis le SVN de la zone.
Même si en théorie il est normalement possible de commit depuis SVN en allant par exemple dans le dossier video_accessible/trunk/, Github va refuser le commit car il vient d'un utilisateur qui n'a pas le droit de commit sur le repository, sauf à avoir aussi un compte Github et à avoir les droits de commit sur le repo concerné.

Question à trancher :
----

Peut-être faudrait-il définir un rangement dans _externals_ pour eviter que ce soit le bazar, en faisant un checkout dans un dossier

github.com/githubUser/nomDuRepository

pour eviter les collisions ?
(mais ça fait apparaitre le nom du user github dans l'arbo de la zone, ce qui personnalise et peut être interprété comme contraire à la notion de dev collaboratif...)

--
Cédric

fil · Mars 5, 2014, 9:38

2014-03-05 10:36 GMT+01:00 Cédric Morin <cedric@yterium.com>:

github.com/githubUser/nomDuRepository

pour eviter les collisions ?

bonne idée mais on peut se limiter à github

(mais ça fait apparaitre le nom du user github dans l'arbo de la zone, ce
qui personnalise et peut être interprété comme contraire à la notion de dev
collaboratif...)

github permet de créer autant de users et groupes qu'on veut, on peut donc
imaginer éventuellement un groupe "non personnalisé"

-- Fil

Severo · Mars 5, 2014, 9:50

El 05/03/14 10:36, Cédric Morin escribió:

mais il devient possible de référencer un plugin développé sur github
sur plugins.spip.net

merci pour les tests, c'est intéressant.

Question à trancher :
----

Peut-être faudrait-il définir un rangement dans _externals_ pour eviter
que ce soit le bazar, en faisant un checkout dans un dossier

github.com/githubUser/nomDuRepository

pour eviter les collisions ?

À mon avis, le fait de mettre github.com/githubUser/nomDuRepository ou
seulement nomDuRepository pour cacher le nom de l'utilisateur ne change
à mon avis rien au "problème" principal qui est celui des droits de commits.

La zone est un lieu de développement collaboratif, où tous les membres
ont le droit de commit sur tout. Le fait de lier vers des dépôts
externes où les droits de commits sont restreints et différents pour
chaque dépôt relève d'une autre logique.

Du coup, comme le propose @fil, peut être passer par un dépôt
intermédiaire github/spip-zone, ou plutôt créer un groupe sur github
avec les mêmes membres que la zone (ou ouvert à la souscription de la
même façon que la zone), et ne référencer sur la zone que les dépôts qui
donnent les droits de commit à ce groupe spip-zone.

cerdic · Mars 5, 2014, 9:51

Fil a écrit :

github permet de créer autant de users et groupes qu'on veut, on peut donc imaginer éventuellement un groupe "non personnalisé"

Mais ce n'est pas un alias :

En pratique ça veut dire qu'il faut transférer son repo sur, par exemple, le groupe spip-zone, et alors soit tu en perds les droit d'admin, soit il faut y mettre tout le monde admin.

Du coup on perds totalement la finesse de droit d'utilisation des repos Github, qui me permet de gérer mon repo, d'être sur que seules les Pull Request que j'aurais approuvées seront intégrées etc.

Alternative, forker le repo sur le groupe spip-zone, mais alors pour faire une mise à jour du zip de plugins.spip.net, je dois pousser sur mon repo, synchroner le repo spip-zone (ce qui suppose que j'ai les droits), et aller modifier le tags dans archivelist.txt. Ça alourdit…

Cédric

Franck · Mars 5, 2014, 10:00

Question à trancher :
----

Peut-être faudrait-il définir un rangement dans _externals_ pour eviter que
ce soit le bazar, en faisant un checkout dans un dossier

github.com/githubUser/nomDuRepository

pour eviter les collisions ?
(mais ça fait apparaitre le nom du user github dans l'arbo de la zone, ce
qui personnalise et peut être interprété comme contraire à la notion de dev
collaboratif...)

--
Cédric

----

Alors là, franchement bravo cédric et merci, car cela simplifie grandement
la recherche de plugin.

Concernant la question, je pense qu'il n'est pas mal de faire apparaitre le
nom du dépôt, dans le sens ou si actuellement, github est très à la mode, il
n'est quand même pas le seul qui existe et dans l'avenir peut-être qu'un
autre sera mieux.
Après concernant la présence du "githubUser" je pense qu'il y a plusieurs
cas à voir:

- Quand c'est celui d'une entreprise ?
- Quand c'est celui d'une personne ?

Si les gens souhaitent faire leur "troll" car c'est le plug de x, y ou de Z
de toute façon, ils pourront toujours le faire en allant voir sur github,
donc, je ne pense pas que cela doit rentrer en ligne de compte.
C'est pour cela que je ne vois pas de problème quand il s'agit d'une
personne.

Après concernant le cas d'une entreprise, c'est beaucoup plus "délicat" et
je pense qu'il faut peut-être mettre des règles très clair dès le départ car
sinon, l'on risque de voir les plug de moins en moins héberger sur la zone

rastapopoulos · Mars 5, 2014, 10:05

Le 05/03/2014 10:51, Cédric Morin a écrit :

Du coup on perds totalement la finesse de droit d'utilisation des repos
Github, qui me permet de gérer mon repo, d'être sur que seules les Pull
Request que j'aurais approuvées seront intégrées etc.

C'est le point qui pour l'instant me fait dire que c'est à la fois bien et pratique, et à la fois ambigu.

En effet, les "outils de spip-zone" ce n'est pas juste le dépôt SVN commun, mais aussi le zippeur, la publication auto sur plugins.spip, la liaison auto avec les pages de doc sur Contrib, etc.

Or, du coup, on peut profiter des outils et automatisme de la communauté, mais *sans être dans une logique coopérative* puisque le dépôt Github est à la charge d'une unique personne qui fait bien ce qu'elle veut (toi peut-être que tu acceptes un max de pull request, ou pas : mais chacun fait ce qu'il veut).

C'est un point qui me semble bizarre.

Plus bizarre d'après moi que d'accepter sur spip-zone des trucs en rapport avec des transferts d'argent.

De mon point de vue/ressenti personnel, le fait d'être dans une logique coopérative est le point le plus important.

--
RastaPopoulos

cerdic · Mars 5, 2014, 10:16

RastaPopoulos a écrit :

En effet, les "outils de spip-zone" ce n'est pas juste le dépôt SVN commun, mais aussi le zippeur, la publication auto sur plugins.spip, la liaison auto avec les pages de doc sur Contrib, etc.

Oui mais en l'occurence la publication sur plugins.spip et sur Contrib sont des choses dont il a toujours été accepté qu'elles ne soient pas liées à SPIP-Zone.

Ici il s'agit plutôt de contourner une limitation technique actuelle qui est que je peux pas référencer manuellement le plugin autrement qu'en passant par le zippeur de la zone, mais c'est plus un hack pour rétablir l'ouverture de plugins.spip qu'un dévoiement de SPIP-Zone…

Mais tu as raison que cela pose du coup la question de ce qu'on va accepter de référencer sur plugins.spip ; qui devient incontournable car utilisé par SVP (j'ai eu plusieurs fois la remarque de "on trouve pas le plugin X par SVP").

Et en effet, par exemple (question toute théorique car en pratique ne s'y prête pas du tout sur cet exemple), est-ce qu'on est susceptible de référencer un plugin de paiement bancaire sur plugins.spip.net ?
Ou un plugin d'affichage de publicité ? ou je ne sais quoi de pire encore ?

Bref, au delà de l'aspect purement technique, il faut peut-être préciser la charte/règle de fonctionnement.
Même si pour le moment on peut aussi se réfugier derrière le fait que comme on passe par la zone, c'est la charte de SPIP-Zone qui s'applique… (mais pour moi c'est temporaire, à un moment on pourra référencer un zip depuis un formulaire et court-circuiter totalement la zone).

Cédric

Severo · Mars 5, 2014, 10:17

El 05/03/14 11:05, RastaPopoulos escribió:

De mon point de vue/ressenti personnel, le fait d'être dans une logique
coopérative est le point le plus important.

Exact, c'est surtout ça le point à discuter, à mon avis.

Moi je trouve ça parfait de fonctionner par Pull Request, qui peuvent
être commentées, modifiées, jusqu'à être intégrées quand elles
conviennent. ça permet de travailler sur tout un ensemble de commits
dans son coin, et de proposer l'ensemble quand c'est prêt. Bon, c'est
les avantages de git sur svn.

La solution est à mon avis de faire des Pull Request vers un dépôt sur
github/spip-zone, où tous les contributeurs peuvent commenter, accepter
le commit, etc, et groupe dans lequel tout le monde peut être intégré
comme commiteur, à condition d'en faire la demande, comme pour la zone.

À l'inverse, s'il s'agit d'un dépôt où seul une personne a le contrôle
sur ce qui est intégré ou pas, alors ce n'est plus la logique de la
zone. Par contre il est possible de proposer des nouveaux "dépôts"
(plugins.spip.net/plugins-paquets-et-depots.html) indépendants de la
zone pour référencer les plugins sur plugins.spip.net, et comme ça il
apparaît clairement que la "gouvernance" est différente.

rastapopoulos · Mars 5, 2014, 11:00

Effectivement, tu as raison : la "charte de spip-zone", et la "charte de Contrib" ne sont pas la même (pas aussi bien explicitée l'une que l'autre d'ailleurs).

Or la "charte de plugins.spip" est plutôt à mettre dans le même sac que celle de Contrib, je suis d'accord.

Du coup, comme tout cela fait partie des sites communs, j'en viens plutôt à penser qu'il serait mieux d'avoir *une seule charte unifiée* pour l'ensemble de outils de la communauté, mais qu'à l'intérieur de celle-ci, on indique clairement lorsqu'il y a des droits différents suivant les outils.

Ce ne serait plus la "charte de spip-zone", mais la "charte des outils de la communauté". Avec pour chaque outil des droits et devoirs possiblement différents.

Comme le dit Sylvain, je trouve aussi que c'est une bonne idée que les plugins non-coopératif (github induit un fonctionnement hiérarchique par défaut) soient dans un dépôt séparé, et ajouter ensuite ce dépôt à plugins.spip.

Pour ce qui est de quelles contributions accepter, je suis d'accord aussi pour que ce soit plus précis (dans cette nouvelle charte unifiée). À discuter donc dans le cadre la rédaction de cette charte.

(NB : Mais au premier abord, pour moi, le fait de "transférer de l'argent" n'est pas un critère, cela peut servir à faire des dons à une association, et cela peut avoir sa place dans les outils pour tous, y compris même sur spip-zone. En revanche "envoyer des infos privés à GAFAT sans prévenir" ça c'en est un pour moi.)

--
RastaPopoulos

azerttyu · Mars 5, 2014, 11:07

Ciao

Je n'ai pas tout compris aux échanges précédents mais il est tout à
fait possible de mettre un plugin de la zone en git et le synchroniser
avec github.

C'est ce qu'on fait déjà avec le core. et pour lequel on a déjà
intégré un PR fourni depuis github.

Km

cerdic · Mars 5, 2014, 1:16

Bon, j’entends les arguments, mais comme le but est de résoudre un problème concret qui existe déjà avant d’en poser de nouveaux je propose le plan d’action/modus operandi suivant :

Pour tout de suite :

pour le moment on s’autorise à mettre dans le dossier externals de la zone des plugins github (ou autre) dont le référencement fait défaut sur plugins.spip.net
en compromis on les checkoutera dans un dossier github/nomdurepository (en gérant au cas par cas les éventuels homonymes, cas rare a priori), pour éviter de mettre en avant le nom du contributeur ou société
on ajoute un fichier lisezmoi.txt à la racine de externals pour préciser les règles particulières qui s’applique à ce dossier :
plugins externes à la zone visant à être proposés en zip dans SVP
mais code collaboratif qui accepte les contributions extérieures (PR)

Pour la suite :

on explore la possibilité d’utiliser un groupe spip-zone sur Github et d’y développer des projets collaboratifs avec droits donné à tous les commiteurs de la zone (mais il faut avoir un compte sur github aussi, donc a priori gestion manuelle des droits à faire…)
on met en place un dépôt séparé qui aura pour objectif d’accueillir les projets externes qui ne fonctionnent pas selon la charte de la zone

Des objections ?

rastapopoulos · Mars 5, 2014, 1:19

Le 05/03/2014 14:16, Cédric Morin a écrit :

Des objections ?

Aucune, tout cela me parait très bien.

Vive tou⋅te⋅s ! \o/

--
RastaPopoulos

eric_tonton · Mars 5, 2014, 1:34

Le 5 mars 2014 14:16, Cédric Morin <cedric@yterium.com> a écrit :

Pour la suite :
- on explore la possibilité d'utiliser un groupe spip-zone sur Github et
d'y développer des projets collaboratifs avec droits donné à tous les
commiteurs de la zone (mais il faut avoir un compte sur github aussi, donc
a priori gestion manuelle des droits à faire...)
- on met en place un dépôt séparé qui aura pour objectif d'accueillir les
projets externes qui ne fonctionnent pas selon la charte de la zone

A ce propos, les zips ne se créent que par déclaration dans un fichier de
type archivelist.txt.
Il en existe plusieurs, c'est ce que l'on appelle un dépôt SVP.

Je pense que pour ces nouveaux plugins il faudrait créer un archivelist_ext
ou archivelist_github carrément si ils viennent que de là et les déclarer
ainsi.
Il faudra donc le charger explicitement dans SVP pour y avoir accès mais ça
me parait très grave.
En tout cas, je ne pense pas qu'ils doivent être intégrer à l'archivelist
de spip-zone.

++
Eric

cerdic · Mars 5, 2014, 1:37

Ah cool, bonne idée !
Je prépare ça et il restera que la déclaration sur plugins.spip.net !

Eric a écrit:

Le 5 mars 2014 14:16, Cédric Morin <cedric@yterium.com
mailto:cedric@yterium.com> a écrit :

Pour la suite :

on explore la possibilité d’utiliser un groupe spip-zone sur
Github et d’y développer des projets collaboratifs avec droits
donné à tous les commiteurs de la zone (mais il faut avoir un
compte sur github aussi, donc a priori gestion manuelle des droits
à faire…)

on met en place un dépôt séparé qui aura pour objectif
d’accueillir les projets externes qui ne fonctionnent pas selon la
charte de la zone

A ce propos, les zips ne se créent que par déclaration dans un fichier
de type archivelist.txt.
Il en existe plusieurs, c’est ce que l’on appelle un dépôt SVP.

Je pense que pour ces nouveaux plugins il faudrait créer un
archivelist_ext ou archivelist_github carrément si ils viennent que de
là et les déclarer ainsi.
Il faudra donc le charger explicitement dans SVP pour y avoir accès
mais ça me parait très grave.
En tout cas, je ne pense pas qu’ils doivent être intégrer à
l’archivelist de spip-zone.

++
Eric