C'est justement tout le noeud du problème. La guéguerre qui a opposé Debian et les rubyistes, c'est un conflit entre administrateurs et développeurs.
En l'occurence, le système des gems ont été faites par des développeurs, pour des développeurs, et lesdits développeurs n'ont rien à caler du fait que d'autres non-développeurs ou d'autres non-rubyistes essaient d'utiliser le code. Ceux qui veulent utiliser un projet ruby n'ont qu'à apprendre à se servir de ruby et de son écosystème.
De l'autre côté, APT a été fait par et pour des administrateurs systèmes, qui veulent pouvoir utiliser $project sans se soucier du langage avec lequel il est programmé. Après tout c'est un détail d'implémentation, et je ne vois pas pourquoi je devrais apprendre tout ce qui a trait à ruby, gems ou whatever juste pour utiliser, par exemple, redmine ou tracks. apt-get install redmine tracks devrait suffire.
Le pire est que les deux points de vue ne sont pas forcément incompatibles: une histoire similaire a eu lieu dans le monde python avec setuptools et les "eggs", qui, comme les gems, sont très intrusifs même au niveau du code et ne sont pas "compatibles" avec une distribution des packages ala APT. Le problème a été résolu avec l'évolution vers "pip".
En fait, en lisant la page du wiki de Debian à propos de RubyGems il semblerait qu'il soit en fait possible pour les rubyistes de rendre leur code packageable avec un peu d'attention, un peu comme la dualité distutils/setuptools de python.
La teneur de ma question était donc: 'est-ce que la communauté ruby a gagné en maturité ou est-ce que ce dernier changement consiste encore à montrer le mauvais doigt aux distributions?'
[^] # Re: Des Gems pour la bibliothèques standard?
Posté par nud . En réponse à la dépêche Petites brèves : Ruby 2.0, DataMapper et RubyLive. Évalué à 2.
C'est justement tout le noeud du problème. La guéguerre qui a opposé Debian et les rubyistes, c'est un conflit entre administrateurs et développeurs.
En l'occurence, le système des gems ont été faites par des développeurs, pour des développeurs, et lesdits développeurs n'ont rien à caler du fait que d'autres non-développeurs ou d'autres non-rubyistes essaient d'utiliser le code. Ceux qui veulent utiliser un projet ruby n'ont qu'à apprendre à se servir de ruby et de son écosystème.
De l'autre côté, APT a été fait par et pour des administrateurs systèmes, qui veulent pouvoir utiliser $project sans se soucier du langage avec lequel il est programmé. Après tout c'est un détail d'implémentation, et je ne vois pas pourquoi je devrais apprendre tout ce qui a trait à ruby, gems ou whatever juste pour utiliser, par exemple, redmine ou tracks. apt-get install redmine tracks devrait suffire.
Le pire est que les deux points de vue ne sont pas forcément incompatibles: une histoire similaire a eu lieu dans le monde python avec setuptools et les "eggs", qui, comme les gems, sont très intrusifs même au niveau du code et ne sont pas "compatibles" avec une distribution des packages ala APT. Le problème a été résolu avec l'évolution vers "pip".
En fait, en lisant la page du wiki de Debian à propos de RubyGems il semblerait qu'il soit en fait possible pour les rubyistes de rendre leur code packageable avec un peu d'attention, un peu comme la dualité distutils/setuptools de python.
La teneur de ma question était donc: 'est-ce que la communauté ruby a gagné en maturité ou est-ce que ce dernier changement consiste encore à montrer le mauvais doigt aux distributions?'