Moneta : émulateur de miroir applicatif - Page 1

Hop, un premier projet perso à présenter : Moneta, un émulateur de miroirs applicatifs.

Le but est d'avoir sur un même site web différents types de dépôts (pour l'instant : Debian/Ubuntu, Yum, Python et Maven ) pour y publier ses propres paquets, afin de pouvoir installer ses propres paquets de la même façon que les paquets classiques, sans avoir à les mélanger avec des miroirs des dépôts officiels. A priori, c'est plutôt ciblé pour un intranet que pour internet, si possible avec authentification Kerberos.
Il va donc reproduire toutes les URL nécessaires au fonctionnement du miroir choisi.

On peut créer un nouveau dépôt en deux clics, en choisissant les groupes pouvant uploader les paquets. On peut donc facilement avoir un dépôt par projet, avec des droits spécifiques. On pourrait également mettre des droits en lecture, mais quasiment aucun système ne le permet  
Uploader un paquet se fait en une requête cURL, sachant qu'on peut ajouter ultérieurement une signature (GPG ou OpenSSL).
Accessoirement, l'utilisation des miroirs est systématiquement expliquée sur la page d'accueil des miroirs émulés.



Pour le code, c'est du Python + Django, je ne me suis pas posé trop de questions ^^

doc incomplète
Github

Pour l'instant, ça fait uniquement Python, Maven, Aptitude et Yum, je pense rajouter deux-trois trucs plus tard (Ruby, notamment).

(enfin, je suis preneur de vos solutions pour déployer et installer vos projets ^^)

L'idée est très bonne C'est amusant ça me semble en opposition complète avec la mode actuelle qui est d'écrire son propre package manager pour chaque nouvelle sous-techno un minimum utilisée (voire en écrire plus d'un, tant qu'à faire).

Tu as ré-implémenté certains (tous?) des protocoles utilisés, ou bien tu t'es basé sur les implémentations existantes à chaque fois ?

Merci ^^
En effet, je trouve ça assez pénible d'avoir autant de miroirs que de technos, et il n'est pas évident d'avoir la même méthode de déploiement pour ses propres applis que pour les paquets classiques quand on ne veut pas les mettre sur les miroirs officiels.

J'ai tout réimplémenté, mais au final c'est assez peu de boulot. En gros, à chaque fois il y a trois trucs à faire :
* ouvrir le paquet pour extirper ses métadonnées (sauf que pour les .jar, ce n'est pas franchement normalisé en pratique, il faut donc les passer en paramètres à l'upload),
* (yum et apt) générer les fichiers d'index : c'est essentiellement remplir des template avec les métadonnées récupérées donc pas grand-chose à faire,
* répondre aux différentes URL demandées : c'est le plus facile, soit il faut envoyer le fichier demandé, soit un des fichiers d'index, soit un template de quelques lignes.

En pratique, le plus pénible est soit d'extirper les métadonnées (le .deb est en fait un .ar contenant des .tar.gz, et j'ai dû implémenter le format .ar en python), soit de comprendre le format des miroirs (qui est très rarement documenté).

J'ai pensé faire Ruby, qui a un format de miroir tout bête, mais dont le fichier d'index est un objet Ruby sérialisé (donc pas du tout conçu pour être utilisé avec un autre langage). Ils auraient pu prendre du JSON compressé…

Et globalement, aucun système de packaging (à ma connaissance) ne permet d'authentification correcte des machines. APT est le mieux à ce niveau, il permet quand même d'utiliser des certificats SSL. Sinon, Maven permet le login / mdp (chouette…), et c'est tout

OK, donc c'est facilement extensible à d'autres technos... bon à savoir, je trouve le package manager officiel de .NET (NuGet) complètement pourri donc peut-être qu'un jour si j'ai le courage...

Qu'a-t-il de pourri ? Je n'ai jamais fait de .Net, et encore moins de NuGet.

Il n'a pas été conçu initialement pour gérer les dépendances sur plus d'un niveau. Du coup il est souvent incapable de s'en sortir quand l'un des tes paquets dépend d'un autre, ou bien que deux paquets ont une dépendance commune mais pas sur la même version. Comme ce défaut remonte assez tôt dans la conception, ils ont pu résoudre les bugs "faciles" (par exemple pendant un moment il croyait détecter des dépendances circulaires et refusait de continuer), mais il en reste qui ont assez peu de chances d'être corrigés proprement un jour. Au final c'est un gestionnaire de paquets que je trouve de très mauvaise qualité, et malheureusement c'est celui qui a été choisi pour être intégré par défaut à Visual Studio (peut-être parce que c'était le seul).

Zeph (./7) :
Il n'a pas été conçu initialement pour gérer les dépendances sur plus d'un niveau.

C'est quand même assez dingue d'avoir fait un choix de conception pareil pour un gestionnaire de packages, surtout à notre époque.

C'est quand même franchement bizarre d'avoir pris un truc comme ça

Surtout quand il y a des paquets et des gestionnaires de paquets relativement indépendants de la techno (rpm + dnf est pas mal, par exemple)

Deux liens trouvés rapidement, j'imagine qu'il doit y avoir quelques autres tonnes d'articles qui expliquent pourquoi NuGet est si pourri : http://arstechnica.com/civis/viewtopic.php?f=20&t=1229439 ; http://www.blogcoward.com/archive/2012/12/23/More-fun-with-Nuget-or-NuGet-Still-Sucks.aspx

mais du coup, si je comprends bien, c'est plutôt le client nuget qui est foireux, non ?

C'est surtout ça oui, je ne sais pas si les specs ont été assez épargnées de ces défauts pour pouvoir faire un client qui marche mieux, mais c'est probable.

Ça voudrait dire qu'il y a des specs, ça serait déjà un bon signe

J'ai regardé un peu plus en détail le packaging Ruby.

Je trouve quand même vraiment dommage que le serveur et les packages soient totalement liés au langage :
* l'index du miroir est du Ruby sérialisé (avec des classes spécifiques Ruby),
* le fichier décrivant chaque package est du Ruby également, donc pénible à parser.

grrrrr

On peut comprendre qu'ils n'aient pas pensé que ça pouvait être gênant, mais c'est quand même un choix dommage. C'est difficile à déserialiser, des classes Ruby ?

Zeph (./17) :
On peut comprendre qu'ils n'aient pas pensé que ça pouvait être gênant, mais c'est quand même un choix dommage. C'est difficile à déserialiser, des classes Ruby ?

Le format de la sérialisation n'est pas spécialement compliqué (je viens de faire une lib Python pour le faire, même s'il n'est pas documenté — tout comme le code source, d'ailleurs), mais il faut que les classes correspondantes existent en Python. Autant c'est facile pour des classes comme int/float/array/hash, autant c'est moins évident quand c'est du « Gem::Version » :/ (et c'est d'autant plus inutile que cette classe ne contient que le numéro de version).
Le fichier d'index aurait très bien pu être du JSON (c'est une liste de triplets de string), ça n'aurait rien changé pour eux.

J'ai finalement fait le miroir Ruby, mais il y a un appel à Ruby directement pour générer un fichier (comme c'est à l'upload d'un gem, ce n'est pas trop grave).

J'en ai profité pour faire miroir Jetbrains pour les plugins IntelliJ ou PyCharm, on peut donc maintenant faire des miroirs Debian/Ubuntu, Yum, Python, Ruby, Jebtains et Maven. Prochaine étape : miroir Shinken pour les packs de supervision.

Pour NuGet, ça n'a pas l'air compliqué à faire, je vais peut-être le rajouter.