[spip-dev] checkout.php intégré dans spip-cli

Dev
1

Comme expliqué dans ce commit, checkout.php est intégré à 99% dans spip-cli :
https://git.spip.net/spip-contrib-outils/spip-cli/commit/f8c6ac694c46591f19db008998c301b4bd0407d0

Comme d'hab avec Console : "spip help dl" ou "spip dl -h" pour avoir la jolie aide

spip-cli, avec sa commande "spip dl" est donc désormais parfaitement à jour de notre architecture, et fait même bien plus (n'importe quel dépôt SVN, Git, FTP).

À vos tests ! (sachant que ça va encore bouger un peu, cf ci-dessous)

## Différence avec l'ancienne version

Avant l'option raccourcie -r correspondait à --release (pour demander une version exacte stable, un tag), mais désormais ça correspond à --revision pour suivre checkout.php.
La version raccourcie de --release devient -R (majuscule), mais n'est plus utilisée pour le moment.

Pour le mode "SPIP complet", c'est désormais en Git, et plus en SVN, puisque repris de checkout.php.

## Différences mais qui doivent revenir comme avant

Pour le moment checkout.php a été intégré tel quel, et du coup comme dit dans le log, pour le mode "SPIP complet" ça télécharge du DEV par défaut. Ce que je ne trouve pas super. Je pense que je vais refaire un passage dessus pour retrouver l'ancien comportement et toujours avoir du stable par défaut. Celleux qui veulent du dev savent manipuler les options.

En lien avec le point précédent, pouvoir demander du stable d'une branche donnée X ou X.Y (la dernière stable de 3, la dernière stable de 3.1…) comme avant, avec --release. Ce mode a complètement disparu pour l'instant (puisque n'existe pas dans checkout.php).

Si on arrive à remettre ces deux points, il n'y aura quasiment pas de différence avec avant.

## Différence avec checkout.php

Pour l'instant je n'ai pas (encore ?) repris le mode "force" qui supprime tout et refait, un truc dans ce genre. Mais c'est la seule chose pas reprise il me semble.

Et "spip dl" sait télécharger dans le dossier courant, alors que checkout.php demande toujours d'être ailleurs (dans le dossier parent ou complètement ailleurs)

2

Hummmmmmmm merci du Taf
j’ai même l’impression que cela a été cousu main.

Je connais un Mec qui connais un type qui a essayer GIT Alors comme en local il essayé ./checkout.sh, ben il va recommencer pour tester spip-cli pour passer une mutualisation spip en GIT

3

Bonne nouvelle !

Qu'en est-il pour les mises à jour ? La commande core:mettreajour
détecte automatiquement si c'est une installation en git, svn ou ftp ?

4

Comme expliqué dans ce commit, checkout.php est intégré à 99% dans spip-cli :
Refonte complète de la commande "dl". On intègre à peu près tout checkout.php... (f8c6ac69) · Validations · spip-contrib-outils / spip-cli · GitLab

Comme d'hab avec Console : "spip help dl" ou "spip dl -h" pour avoir la jolie aide

spip-cli, avec sa commande "spip dl" est donc désormais parfaitement à jour de notre architecture, et fait même bien plus (n'importe quel dépôt SVN, Git, FTP).

À vos tests ! (sachant que ça va encore bouger un peu, cf ci-dessous)

ok alors j'ai parlé trop vite sur IRC
j'vais installer spip-cli + composer et j'ai crier : ça marche du feu de dieu

et bien non j'ai droit a
$ ./spip.sh dl

[deprecated] Veuillez utiliser les executables SPIP-Cli du répertoire bin.
#!/usr/bin/env php
. n’est est pas sur le bon dépôt Git.

une idée ?

5

Euh ben t'essayes de télécharger SPIP en étant dans le répertoire où est installé spip-cli là… je vois pas comment tu peux espérer que ça puise marcher.

Avant de faire un retour, commence déjà par suivre la doc, pour installer la commande dans le path des binaires du sytème (que ce soit en global ou juste pour tel utilisateur). Et donc pouvoir utiliser la commande spip n'importe où, en allant dans n'importe quel dossier.

6

ok alors j’y retourne en suivant la doc de Ok je suis null …, je cherche donc

7

il manquait de mettre "sudo" partout, pour faire en super utilisateur puisque c'est pas dans ton dossier user, ça pouvait se deviner quand même :slight_smile:

8

ouep j'avais pas vu le #
dsl

9

Sous linux, c'est une très mauvaise habitude que d'utiliser sudo pour
tous les scripts perso.

spip-cli, composer, npm, checkout.php, ..., tous vos scripts sh ou php
ne doivent pas etre installés avec les droits root.

pour cela, une solution assez simple :

se creer un dossier bin à la racine de son dossier perso : ex
/home/tofulm/bin (mais il peut s'appeler patate), et dans son bashrc, zshrc,

il suffit d'ajouter la ligne :

export PATH=$PATH:/home/tofulm/bin

ensuite, si votre script à l'intérieur de /home/tofulm/bin à les droits
d'execution : chmod u+x mon_script.sh, il pourra etre appelé de partout
dans votre home.

Les liens symboliques fonctionnent aussi

10

Merci !!!

11

C'est l'inverse de comment fonctionne un système unix justement.

Un système unix c'est foncièrement *multi-utilisateurs* à la base. Et c'est évidemment encore plus évident… sur un vrai serveur (au sens le gros truc lointain sur internet). Mais ça se voit aussi vite quand on a un ordi pour la famille aussi, avec plusieurs comptes dessus.

Donc quand on installe un nouveau logiciel, on l'installe *pour tous les utilisateurs*, pas juste pour soi. Sinon c'est anti écologique et surtout anti maintenable. L'admin doit l'installer pour tout le monde, c'est la base sur un système multi-utilisateurs.

Tout le barda de npm, composer, etc, et ça vaut pour les snaps de merde, c'est la mauvaise habitude de penser qu'un système c'est que pour un utilisateur unique (un webdev dans son coin).

Bah non, sur nos serveurs on peut avoir plusieurs utilisateurs, et c'est pas à chacun d'installer 15 fois le même outil. On installe qu'une seule fois Git que je sache. Ça devrait être pareil pour n'importe quel autre outil.

En théorie, on devrait avoir de l'empaquetage pour spip-cli, sauf que ça doit pas être comme nos ZIP, il faudrait une routine pour générer un PHAR à chaque fois qu'on le fait évoluer. Et donc un fichier unique, à mettre dans les binaires globaux, pour tout le monde.

12

Je ne partage pas du tout ton point de vue.

Le compte root n'est pas fait pour distribuer des scripts à tout le
monde. Il a trop de droits.

Le jour où l'un de tes scripts aura un pb de sécu, tu auras laissé le
loup entrer dans la bergerie.

pour partager un script à X users, tu places tous tes users dans un
groupe, tes scripts dans un dossier user avec ce meme groupe qui a le
droit d'execution.

Dans ce cas, root n'intervient pas.

Ce que tu proposes, tu peux le faire sur ta machine locale, mais surtout
pas sur un serveur de prod.

Et cela n'a rien à voir avec "comment fonctionne un système unix" qui
propose justement de limiter les droits à des scripts pour qu'ils ne
puissent pas atteindre le coeur de ton systeme.

Et je ne parle pas des binaires qui sont encore plus obscures :wink:

Ce n'est que mon avis, et sur nos serveurs, je préfère fermer les portes
aux plus de monde possible.

13

Je pige pas cette différence, script, binaire etc. Tout ça ce sont "des logiciels". La commande "git", "svn", même "php", "apache", que tu installes c'est quoi, c'est pas des binaires peut-être ? Ce sont des logiciels, quelque soit la manière dont ils sont codés derrières, en C, en python ou en PHP. Après c'est libre ou pas, donc vérifié par d'autres gens ou pas, et donc de confiance ou pas. T'installes pas "git", "libreoffice" etc avec un différent pour chaque utilisateur, ni même dans le compte d'un group, que je sache. On installe ça une fois pour toute pour tout le monde à la fois.
Et le fait que ce soit installé en global ne change absolument rien aux droits *au moment de l'exécution*, c'est bien tel user précis qui le lance et ça ne va pas au delà de ses droits. Quand tu lances "git" avec un user précis, et qu'il essaye de télécharger dans un dossier où il n'a pas le droit, bah ça marche pas. Pareil pour spip-cli ou n'importe quoi d'autre.

14

Attention changement : le répertoire d'install n'est plus un argument avec une place précise, mais une option --dest ou -d, qu'on met donc où on veut.

Comme avec Console, on peut pas simplement avoir des mêmes arguments qui veulent dire plusieurs choses (l'argument numéro 2 ne peut être que XXX), c'est beaucoup plus logique que ce soit une option. Toujours le dossier courant par défaut.