[spip-dev] [SPIPRemix] Mise en place du dépôt Composer

Dev
1

Salut,

Le développement de la maquette touche à sa fin. Je prévois actuellement la publication de 2 derniers articles…

Avant cela, je reviens sur ce point particulier qui est la mise en place du dépôt Composer.

Dans l’hypothèse où nous déciderions d’intégrer effectivement composer dans le développement de SPIP, il existerait alors plusieurs solutions pour publier les composants de SPIP sur Internet. Toutes sont possibles, cumulables, évolutives.

La plus simple, la plus rapide et la moins gourmande en énergie humaine serait d’utiliser le référentiel principal de Composer, à savoir https://packagist.org. Pour cela, il suffit que les dépôts de code source de chaque composant soient eux aussi accessibles de manière sécurisée sur Internet, qu’ils fonctionnent avec Git ou Subversion, et qu’il soient “conformes” à certaines règles d’organisation que j’ai décrit dans d’autres articles sur le blog de SPIP ou sur le site de la maquette.

C’est ma solution préférée :slight_smile:

Les alternatives demandent un peu d’huile de coude :

Mettre en place notre propre instance packagist nécessite quelques compétences pour le coté infrastructure (Symfony, MySQL, administration système), du temps pour sa mise en place, ses mises à jour, sa personnalisation et son maintien en ligne. Et aussi bien sûr une serveur à gérer.
Coté utilisateur, l’utilisation de composer avec cette instance nécessiterait un peu de configuration sur leurs propres machines.

Utiliser satis, comme nous l’avons fait sur SPIPRemix, pourrait être une solution intermédiaire satisfaisante (ha ha ha). Néanmoins, bien que plus performante en production, elle demande des développements supplémentaires. J’aime beaucoup cet outil, j’y ai contribué un temps, mais il a des limites fonctionnelles qui demanderait pas mal d’implication de la part de la communauté.

Enfin, une solution from scratch demande de tout imaginer… les spipeurs aiment bien faire ça et c’est ce qui rend les choses plus amusantes mais aussi beaucoup plus longues à mettre en œuvre.

Ces alternatives demandent un travail d’analyse, de l’energie et des tests puis des moyens et un effort de communication particulier. Mais ce sont des projets intéressants à mener.

Il ne manque que des volontaires :wink:

Pour rappel : https://spip.lerebooteux.fr/Mise-en-place-du-depot-Composer

Alors ? Vous en pensez quoi ?

Amitiés,

2

Hop,

Salut,

Le développement de la maquette touche à sa fin. Je prévois actuellement la
publication de 2 derniers articles...

D'abord merci pour tout le travail accompli sur cette maquette, et merci aussi pour le spam :stuck_out_tongue:

La plus simple, la plus rapide et la moins gourmande en énergie humaine
serait d'utiliser le référentiel principal de Composer, à savoir
https://packagist.org. Pour cela, il suffit que les dépôts de code source
de chaque composant soient eux aussi accessibles de manière sécurisée sur
Internet, qu'ils fonctionnent avec Git ou Subversion, et qu'il soient
"conformes" à certaines règles d'organisation que j'ai décrit dans d'autres
articles sur le blog de SPIP ou sur le site de la maquette.

C’est ma solution préférée :slight_smile:

+1, je pense qu'il faut préférer la solution la moins coûteuse en temps à condition qu'elle ne nous lie pas à vie à un service externe (ce qui ne semble pas être le cas) et que le service en question est "clean" d'un point de vue "valeurs". D'autant plus que cette solution aurait l'avantage de donner plus de visibilité si j'ai bien compris.

Les alternatives demandent un peu d'huile de coude :

Mettre en place notre propre instance packagist nécessite quelques
compétences pour le coté infrastructure (Symfony, MySQL, administration
système), du temps pour sa mise en place, ses mises à jour, sa
personnalisation et son maintien en ligne. Et aussi bien sûr une serveur à
gérer.
Coté utilisateur, l'utilisation de composer avec cette instance
nécessiterait un peu de configuration sur leurs propres machines.

À voir, mais si ça demande plus de travail aux utilisateurs ça me semble moins sympa.

Utiliser satis, comme nous l’avons fait sur SPIPRemix, pourrait être une
solution intermédiaire satisfaisante (ha ha ha). Néanmoins, bien que plus
performante en production, elle demande des développements supplémentaires.
J’aime beaucoup cet outil, j’y ai contribué un temps, mais il a des limites
fonctionnelles qui demanderait pas mal d’implication de la part de la
communauté.

À préférer à la précédente, mais plus tard, une fois le projet SPIP composer stabilisé ?

Enfin, une solution from scratch demande de tout imaginer... les spipeurs
aiment bien faire ça et c’est ce qui rend les choses plus amusantes mais
aussi beaucoup plus longues à mettre en œuvre.

version cible 99+plus tard :stuck_out_tongue:

3

D'abord merci pour tout le travail accompli sur cette maquette, et merci aussi pour le spam :stuck_out_tongue:

+1000 et tous les bisoux qui vont avec pour le super boulot :slight_smile:

La plus simple, la plus rapide et la moins gourmande en énergie humaine
serait d'utiliser le référentiel principal de Composer, à savoir
https://packagist.org. Pour cela, il suffit que les dépôts de code source
de chaque composant soient eux aussi accessibles de manière sécurisée sur
Internet, qu'ils fonctionnent avec Git ou Subversion, et qu'il soient
"conformes" à certaines règles d'organisation que j'ai décrit dans d'autres
articles sur le blog de SPIP ou sur le site de la maquette.

C’est ma solution préférée :slight_smile:

+1, je pense qu'il faut préférer la solution la moins coûteuse en temps à condition qu'elle ne nous lie pas à vie à un service externe (ce qui ne semble pas être le cas) et que le service en question est "clean" d'un point de vue "valeurs". D'autant plus que cette solution aurait l'avantage de donner plus de visibilité si j'ai bien compris.

Pareil.
Simplicité, efficacité, visibilité

Bon, je ne sais pas exactement qui est packagist.org (packagist.com ?) mais déjà c'est basé sur du code ouvert, et James peut sûrement nous éclairer.

Et pour ce qui est d'être lié à vie, je pense avoir compris qu'on peut reprendre la main à un moment si on n'adhère plus, avec un Satis maison ou autre (au prix d'un changement de repository des paquets).

Donc +1 aussi :slight_smile: