Re: Dépendances rédhibitoire

En même temps, je n'ai jamais formulé ça de cette façon. Ce que je disais était "si j'ai beaucoup de dépendances, c'est parce-que je ne veux pas réinventer la roue". La question de les embarquer / packager avec Paperwork ne m'a jamais été posée jusque là.

Mea culpa ! Effectivement la question n'était pas posée comme ça, mais finalement l'utilisateur s'en fout un peu qu'il y est beaucoup de dépendances, si le logiciel est facile à installer, est à jours, et fonctionne correctement.

Quoiqu'il en soit, je continue à penser que les dépendances sont un problème qui se résoudra tout seul grâce aux gestionnaires de paquets. Si les packageurs font leur travail, un simple "apt-get install paperwork" (par exemple) suffira à l'installer.

Je rejoins Zenitram sur le fait que si tu attends que ça tombe du ciel, tu vas freiner l'adoption de ton logiciel.

Mais dans l'ordre des choses, le packaging et la distribution de Paperwork ne sont pas de mon ressort.

Pour moi, ça veut dire que tu n'as pas envie de faire le packaging (ça je crois qu'on l'a bien compris) et que tu t'en fout d'avoir beaucoup d'utilisateurs tant que tu peux faire marcher le projet. J'ai peur que ce genre de politique ne soit pas très vendeur.

Finalement, pour moi le problème majeur est ailleurs : prenons les choses du point de vue d'un packageur potentiel (j'avoue que je me suis posé la question, mais je suis moyennement motivé):

• 13 dépendances à packager : c'est énorme ! Allez, disons que 4 ou 5 sont déjà disponibles sur les dépôts des principales distrib Linux. Il en reste encore 8 ou 9 ! Et ça pour chaque distrib ciblée. Tu te représentes la quantité de travail? Alors qu'avec un poil de volonté du développeur on pourrait avoir un paquet par distrib à faire. Même si le problème des dépendances est difficile (j'ai pas de solution miracle), ça donne moyennement envie.
• Portabilité ? : Le logiciel est en Python, donc il pourrait potentiellement viser Windows et/ou Mac OS. Oui mais avec la gestion actuelle des dépendances, c'est déjà un boulot de titan de le packager pour des distribs non debian. La encore je suis un peu déçu.
• Gestion du projet : La gestion des dépendances (Quelles libs on utilise? Quelles libs on peut virer? Quelles versions?), c'est le développeur qui doit les faire, j'espère qu'au moins la dessus on est d'accord. Seulement si le développeur ne tient compte que du code et pas du packaging, le logiciel peut vite devenir une horreur à packager. Par exemple si le dev choisi d'intégrer une lib originale que personne n'utilise à chaque release.
• Le côté ingrat du boulot : Finalement, je préfère largement coder que packager, et je suis sûr que c'est le cas d'une majorité de gens. Donc si le travail n'est pas préparé par le project leader et qu'il n'est même pas valorisé, il y a peu de chance que je le fasse.

Encore une fois, je salue ton travail car il y a du mérite ! Mais je pense que mes critiques sont fondées, en tout cas c'est la réflexion que je me suis faite. Bref le problème du packaging est difficile dans ton cas, en plus c'est du Python et c'est pas le moment adéquate pour vendre du Python. Mais je suis sûr qu'en y mettant les formes et en fournissant un peu de travail, tu peux arriver à un résultat très prometteur.