Page 3 sur 7Précédent 1, 2, 3, 4, 5, 6, 7 Suivant[débat]zip ou autoextractible ? => débat général

[Tuxmouraille]

Bien sûr il est possible d'extraire l'exe avec 7zip et de remettre les bons dossiers à leur place, mais franchement, je pense que ça n'en vaut pas la peine.

J'allais justement dire que je suis d'accord de reprendre l'architecture des dossiers des paquets de PortableApps mais pas l'auto-extractible et proposer de faire une application qui convertira automatiquement les paf.exe en .zip.

D'ailleurs, c'est pas pour rien que les .xpi (extension firefox) ou les .jar sont des .zip renommés.

Et l'OpenDocument...

Donc ça a l'air compatible. Par contre aucune version n'est disponible pour python 2.6 pour windows... Je cherche maintenant comment faire pour l'installer...

LZMA s'est le format de compression de 7zip. Donc si ça marche pas tu peux toujours utiliser 7zip en ligne de commande pour les ouvrir.

Il y a moyen de voir ce que donne la GUI avec 7zip (en clair faire 7zip auto extractible) pour que je me puisse me faire une idée de l'interface si elle est si minimale que cela ??

Si tu es sous GNU/Linux, sous Bash c'est quelque chose comme ça:

Code: Tout sélectionner

cat 7zS.sfx config.txt archive.7z >> archive.exe

Même si j'ai lancé le débat, je pense aussi que le .zip reste encore aujourd'hui le meilleur format. Peut être qu'un jour il en saura autrement mais nous avons pu arriver sur le problème vraiment important des applications : la non standardisation des paquets. Si j'ai lancé le débat c'était surtout pour voir ce qu'en pensaient les utilisateurs.

Et d'ailleurs, il faut même aller plus loin en remarquant que chaque application n'a pas forcément le même lanceur non plus. Du coup, comme faire une documentation pour les lanceurs s'ils ont chacun leurs spécificités ?

Je suis d'accord, il faut harmonise, l'architecture des dossiers et les lanceurs.
C'est pour quoi en prévision de l'arrivée de synapps ou autre, il faudrait commencer à définir la structure des dépôts logiciels. Je propose de s'inspirer des dépôts apt, en simplifiant au possible, et en n'ayant que deux catégories: main pour les paquets certifiés et community/unstable/uncertify pour les paquets pas encore certifiés.

[Roromis]

J'allais justement dire que je suis d'accord de reprendre l'architecture des dossiers des paquets de PortableApps

Je suis d'accord. J'ai essayé de partir de la structure de la Framakey pour faire quelque chose qui rendrait la mise à jour d'un logiciel la plus simple possible, et je me suis retrouvé avec quelque chose de très ressemblant (un dossier App qui contient en gros tout sauf l'executable et un dossier Data vide à l'origine qui contient ensuite la configuration (en gros tout ce qui devrait-être backupé avec la structure actuelle)).
Edit: Il faudrait cependant ajouter des informations au fichier appinfo.ini. On pourrait par exemple essayer de mettre en place un système de dépendances.

LZMA s'est le format de compression de 7zip. Donc si ça marche pas tu peux toujours utiliser 7zip en ligne de commande pour les ouvrir.

Effectivement, j'avais regardé le code de UniversalExtractor, et c'est comme ça que j'ai vut que 7zip était compatible avec NSIS, mais je préfère ne pas utiliser d'executable externe, qui rendent le logiciel moins interactif (impossible de créer une barre de progression par exemple).

C'est pour quoi en prévision de l'arrivée de synapps ou autre, il faudrait commencer à définir la structure des dépôts logiciels. Je propose de s'inspirer des dépôts apt, en simplifiant au possible, et en n'ayant que deux catégories: main pour les paquets certifiés et community/unstable/uncertify pour les paquets pas encore certifiés.

Personnellement, mon "dépôt" était un fichier xml (http://www.roromis.fr.nf/apps.xml). Au contraire du dépôt apt, il y a une structure à plusieurs niveau (chaque catégorie peut en contenir d'autres). J'avais fait ça pour séparer Applications et Webapps, mais je ne sais pas si le xml est la meilleure solution.
J'ai pris le xml par simplicité (je savais à peu près parser du xml avec python), et pour permettre à n'importe qui de créer facilement un dépôt sur son site (je pense que ça peut non seulement contribuer à l'aspect communautaire du projet (chacun participe en ajoutant ses applications), et permettre d'agrandir considérablement le nombre d'applications disponibles (pour que la Framakey devienne une alternative libre de plus en plus crédible à la Liberkey par exemple)).

[takshil]

Donc, je vais essayer de faire un bilan de tout ce qui a été dit :

volonté globale de conserver le .zip
volonté globale d'uniformiser l'architecture des apps => pour certains, c'est plus qu'une volonté, ce serait une nécessité pour faire évoluer la Framakey.

L'idée de reprendre le format de portableApps semble convaincant pour tout le monde mais il faudrait enlever le .exe final pour avoir une application en .zip ou au format .fmk.zip qui pourrait alors être aussi traité nativement par un installeur framakey.

Si tout le monde est d'accord avec ça, reste plus qu'à faire équipe pour tout ça. Je suis partant bien sûr

Pyg, on t'exclut tout de suite, tu as déjà assez de chose à faire. ça prendra le temps qu'il faut mais bon, je ne pense pas qu'il faut que tu t'impliques dedans.

[Tuxmouraille]

Bonjour,
Ok pour moi takshil.

Par contre pour le fichier appinfo.ini il faut que ce soit du xml, parce que Windows n'utilise pas les même caractères de retour à la ligne que les autres OS, du coup un fichier ini lisible sous Win n'est pas reconnue comme fichier texte sous GNU/Linux, et inversement.

J'ai commencé à faire un installeur hors ligne pour le paquet et finalement la lecture du fichier PortableQuelquechose.xml n'est pas un problème tant qu'il n'y a pas deux fois la même balise.

@Roromis: Est ce que ton application gère les installations hors ligne, à la manière de GDebi sous Debian? Parce que si c'est la cas j'abandonne la mienne, les limitations de AutoHotKey commence à me courir sur le haricot.

Pour le dépôt, je pense qu'il faut à la fois classer les applications en catégories d'usage: Utilitaires, Bureautique, etc, et suivant leur origines: stables, instable ou main, community.
Le premier tout le monde comprend je pense. Le deuxième c'est pour se prévenir des ennuyeux qui pourrais venir se plaindre d'un paquet qui n'est pas assez stable/finit, on les a prévenus.

@Roromis: Est il possible d'avoir plusieurs dépôts?

[Roromis]

Je suis aussi partant pour aider (mais je pense d'abord me concentrer sur l'amélioration et l'adaptation de mon programme au nouveau lanceur).

@Roromis: Est ce que ton application gère les installations hors ligne, à la manière de GDebi sous Debian? Parce que si c'est la cas j'abandonne la mienne, les limitations de AutoHotKey commence à me courir sur le haricot.

Pour l'instant non, mais je peux faire ça assez facilement. Je pense que le résultat sera mieux si je le fait en python (je ne remet pas en cause tes compétences).

Pour le dépôt, je pense qu'il faut à la fois classer les applications en catégories d'usage: Utilitaires, Bureautique, etc, et suivant leur origines: stables, instable ou main, community.
Le premier tout le monde comprend je pense. Le deuxième c'est pour se prévenir des ennuyeux qui pourrais venir se plaindre d'un paquet qui n'est pas assez stable/finit, on les a prévenus.

Je peux ajouter ça à mon dépot xml, ou on peux revoir le format. C'est au choix (je doit revoir la façon dont je gère l'affichque des applications, mon programme est actuellement extrèmemement lent, donc si quelqu'un pense à une autre manière de créer un dépot, je suis ouvert à toutes propositions).

@Roromis: Est il possible d'avoir plusieurs dépôts?

Oui. Les différents dépots peuvent être affichés/cachés dans une liste déroulante (voir screenshot 2), il est possible d'en ajouter/supprimer dans les préférences ou dans un fichier .ini.

[pyg]

Pyg, on t'exclut tout de suite, tu as déjà assez de chose à faire. ça prendra le temps qu'il faut mais bon, je ne pense pas qu'il faut que tu t'impliques dedans.

Pas de souci, au contraire. Pour moi, l'essentiel c'est qu'on avance de façon coordonnée.

Par contre pour le fichier appinfo.ini il faut que ce soit du xml, parce que Windows n'utilise pas les même caractères de retour à la ligne que les autres OS, du coup un fichier ini lisible sous Win n'est pas reconnue comme fichier texte sous GNU/Linux, et inversement.

Là, je serai pour qu'on prenne un peu de recul.
Pour moi, l'idée de fond, ça resterait de coller au format de portableApps pour rendre les applis interopérables (PortableAppsSuite et Synapps, par ex).
Le coup de retours chariots peut facilement être corrigé (par exemple par une détection des types de retours chariots (\r\n sous win) et une substitution par le caractère correspondant sous *nix)

Le vrai manque du appinfo.ini de portableApps, c'est qu'il comporte peu de champs : http://portableapps.com/development/por ... at#appinfo

Cependant, en tant que .ini, rien n'empêche de le compléter par une section [framakey]

Bref, pour moi, ça serait contreproductif que d'aller inventer un nouveau format.
Rien n'empêche de faire des outils utilisant du XML, par exemple, on peut parfaitement imaginer que si synapps utilise du xml, on peut développer un outil qui irait chercher le appinfo.ini dans les .zip, et récupèrerait les infos pour en faire un fichier de depot au format xml.

[Roromis]

Synapps utilise du xml pout le dépot (le xml à l'avantage de permettre créer une arborescence), mais je suis d'accord pour utiliser les fichiers ini pour les appinfo.ini (si ça reste utilisable d'un OS à un autre. Si il faut juste remplacer des caractères je peux m'en charger), c'est bien plus simple et rapide à gérer en python.

Il ne manque pas enormément de champs pour un gestionnaire de paquets, il faudrait ajouter:
- stable ("stable = True" si l'application est stable, "stable = False" si elle instable/en test), mais ça n'est pas nécessaire
- Fichiers et Dossiers de configuration (pour les fichiers qui ne se trouvent pas dans le dossier Data: sous la forme 'file1 = "App/dossier/fichier.ini"...' s'il n'est pas possible de tout mettre dans le dossier Data)

Il faudrait également que "PackageVersion" ne contienne que des points et des chiffres ("3.0.11") et qu'il y ait 4 nombres ("3.0.11.0") si le fichier appinfo.ini est utilisé pour créer le lanceur.

On pourrais éventuellement ajouter un système de dépendances (bien que ça n'ai pas forcément d'utilité), en ajoutant par exemple un dossier Dep/<dependance>-<version> qui serait déplacé par le gestionnaire dans un dossier "Framakey/Dep/<dependance>-<version>" pour que les dépendances soient partagées par tous les programmes (il me semble que PortableApps gère les dépendances dans un dossier CommonFiles, mais je ne sais pas comment ils gèrent ça).

Pour l'affichage, ça m'arrangerait qu'il y ait une icône png 32*32 dans le dossier appinfo.

[Tuxmouraille]

Pour l'instant non, mais je peux faire ça assez facilement. Je pense que le résultat sera mieux si je le fait en python (je ne remet pas en cause tes compétences

Mes compétences en programmations sont limitées par AutoHotkey et NSIS, et limitées en elles même. En plus je suis plutôt paresseux et j'avance pas dans mon apprentissage de C, C++ et Python.

Je peux ajouter ça à mon dépot xml, ou on peux revoir le format. C'est au choix (je doit revoir la façon dont je gère l'affichque des applications, mon programme est actuellement extrèmemement lent, donc si quelqu'un pense à une autre manière de créer un dépot, je suis ouvert à toutes propositions).

Il faut aussi penser à la manière dont on va le gérer au jour le jour. Il faut que les ajouts soient les plus simples possibles. Ce serait bien d'avoir un codeur php pour écrire une interface d'ajout en ligne, en backend et une interface de téléchargement simple avec affichage des catégories sur le coté en frontend.

il me semble que PortableApps gère les dépendances dans un dossier CommonFiles, mais je ne sais pas comment ils gèrent ça

Probablement à l'aide de la variable d'environnement PATH.

[takshil]

Il faut que les ajouts soient les plus simples possibles. Ce serait bien d'avoir un codeur php pour écrire une interface d'ajout en ligne, en backend et une interface de téléchargement simple avec affichage des catégories sur le coté en frontend.

ça c'est ce que je ferai après qu'on ait normalisé toutes les applications. J'y ai déjà réfléchi et déjà commencé. Je proposerai mon travail à Pyg une fois que j'aurai fini.

Pour le téléchargement des applications, je trouve que le site actuel est très bien. Mais ce n'est que mon avis. Il faut voir avec Pyg s'il souhaite avoir un site différent pour la framakey.

[pyg]

On ne s'emballe pas

Une application comme ça a déjà été codée par Leviathan il y a 2 ans. On ne s'en est jamais servi car la logique de dépôt n'avait jamais été mené au bout.
Je ne dis pas qu'il faut l'utiliser, mais qu'en tout cas ça vaut peut être le coup de la réinstaller et de voir ce qu'on peut en tirer.

Par ailleurs, bien que je sois un aficionado des interfaces web, je ne pense pas que ça vaille la peine de se précipiter.
Encore une fois, la règle n°1 de Framakey, c'est "Tout dans le .zip"
Donc, il ne faudrait pas à avoir à saisir 2 fois la description, par exemple (une fois pour le paquet, une fois dans l'interface).
En toute logique, il vaudrait mieux que le fichier .xml du dépôt se construise directement en fonction des applications déposées dans le dépôt lui-même.

Je m'explique :
- on met dans /AppInfo les infos spécifiques à l'application (icone, screenshots, description, etc)
- on package l'appli selon le standard de portableapps (sauf qu'on garde le format .zip)
- on dépose l'appli dans un dossier /repository/stable (validé FK) ou /repository/unstable (en test) ou /repository/contrib (applis non-FK)
- on crée un script (make-repository.(php|sh|autre) ) qui :
-- parse les dossiers de /repository
-- extrait les dossiers /AppInfo de chaque appli et les place dans /repository/(stable|unstable|contrib)/AppsInfo/(nom de l'appli)
-- parse ces dossiers pour créer une sortie /repository/(stable|unstable|contrib).xml (ou .ini, ou autre, ça sera peanuts à changer)
- on lance make-repository en cron régulièrement où à la demande.

L'idée derrière, c'est de surtout ne pas :
- se retaper de la saisie d'info
- éviter la désynchronisation (interface de saisie / fichiers physiques)
- obliger à passer par une interface web (faudrait gérer des niveaux d'accès, des autorisations, des groupes, etc). C'est évidemment faisable, mais ça me parait bancal par rapport à une solution plus "Keep It Simple, Stupid"

Les avantages :
- pas d'interface à coder, à tester et à maintenir, juste un bon gros script qui demande 1 à 2 jours de développement
- possibilité de faire plusieurs sortie en fonction de différents modèles : un depot.xml, depot.ini ou même (application.html) à partir des appinfo
- on dépose l'appli en .zip dans un dossier, le dépôt est mis à jour
- simplicité de mise à jour : imaginons qu'on rajoute un champ dans le AppInfo.ini ("SupportUrl", par exemple), alors il suffit d'ajuster le make-repository pour qu'il le prenne en compte
- on peut fonctionner avec des symlinks pour faire des dépôts spécialisés (par exemple un /repository/archive ou un repository/win98compatible peut se faire en 5mn)

Ce n'est qu'une proposition, hein. Mais l'expérience que j'ai des dépôts, il vaut mieux se baser sur ce qui est physiquement présent que sur le fait que des personnes vont (re)saisir de l'info.

Proposition a discuter, évidemment (je vous demande juste de l'envisager sérieusement )