Discussion :

[Sherwood51]

Bonjour à tous,

je vous copie colle un post que j'ai posté sur le forum d'ubuntu mais pour lequel je n'ai pas encore eu de réponse:

LinCopier - Gestionnaire de copie pour Linux

Bonjour à tous,

ce matin je suis tombé sur un membre du forum qui cherchait une application équivalente à SuperCopier qui puisse fonctionner sur son Ubuntu.

Un petit tour dans la doc m'a envoyé sur minicopier qui ne semble pas vraiment utilisable et qui se veut de plus multiplateforme et donc écrit en Java. Je ne pense pas que cela soit vraiment une bonne idée de faire un logiciel de ce genre en Java et je ne vois pas l'intérêt de le rendre multiplateforme. SuperCopier fait très bien son travail sur Windows. Et de plus cela ne me semble pas très optimisé.

Je suis aussi tombé sur ultracopier qui à l'air beaucoup plus complet et aboutit cependant, je pense plutôt à quelque chose de plus simple.

En gros, les fonctions seraient les suivantes:

- possibilité de mettre en pause une copie en cours
- possibilité de mettre en file des copies
- possibilité de faire des copies dans les répertoires root (avec évidemment un prompt demandant le mot de passe root et présentant un avertissement des risques encourus --> l'idée m'est venu après avoir constaté plusieurs fois les dégats causé par gksudo nautilus...)
- d'autres fonctions si elles se révèlent vraiment utiles mais le but premier serait de rester sobre et simple

Voilà pour l'idée de l'application qui n'en est... qu'au stade de l'idée pour le moment. Et elle ne tournerait donc que sur les plateformes Linux.

Pour l'instant, il y aurait un ami étudiant en informatique à l'université avec moi et donc moi-même sur le projet. Toute personne désirant s'impliquer dans ce petit projet est aussi la bienvenue!
En effet, j'ai encore beaucoup à apprendre sur le développement logiciel et une aide de quelqu'un d'expérience sera toujours utiles. Et aussi, étant tous les deux étudiants et ayant des programmes chargés, le projet avancera à son rythme.

D'ailleurs, se pose aussi la question du langage et des bibliothèques à utiliser.
Je pensais à python et GTK --> des suggestions de la part de développeurs avancés qui proposerait un autre langage/bibliothèque à utiliser à la place?

Bon, je pose déjà les bases, à voir maintenant si cela pourrait intéresser des personnes.

Au plaisir.

Sherwood51

Mes questions principales:
- est-ce que Python vous semble approprié pour un tel projet?
- est-ce que vous pensez que la difficulté du projet est abordable pour de jeunes étudiants motivés mais n'ayant pas forcément beaucoup de temps à consacrer de façon régulière sur un tel projet?

Bref, vos avis d'experts m'intéresse!
Et si quelqu'un aurait envie de rejoindre le projet, cela serait avec plaisir.

[tyrtamos]

Bonjour,

Oui, Python est tout à fait capable de faire ça. Les limites seront à la hauteur de l'ambition du projet et du temps que vous pourrez y consacrer.

J'ai fait pour moi un programme de sauvegarde sélective de répertoires (seulement les fichiers plus récents) avec sélection/exclusions et option miroir (supprime de la destination les fichiers et répertoires qui ont disparu de la source), mais c'était en console et sous Windows. Cependant, j'ai trouvé cela plus complexe que je ne le pensais au départ. Mais c'était d'autant plus intéressant...

Sous linux, je vous conseille de faire un bon cahier des charges qui devra clarifier les limites de votre programme de copie, au moins sur 3 points:

- distinguer une copie d'une sauvegarde. En effet, une sauvegarde est censée copier les fichiers sans les modifier, et les restaurer en place si besoin. Cela pourra changer la manière de traiter, par exemple, la copie des liens symboliques en fonction de l'emplacement visé, ou de savoir s'il faut recopier les metadatas systématiquement. Alors qu'une copie est une "appropriation" des fichiers copiés par l'utilisateur qui copie.

- savoir si vous limitez la copie aux données utilisateurs (répertoires, fichiers "normaux", liens symboliques, éventuellement limité aux points de montage), ou si vous l'étendez à la copie de répertoires système. Dans le second cas, vous aurez à traiter la copie des fichiers spéciaux comme les copies de fichiers de périphériques (dev), les sockets locales et les tubes nommées. Le cas des liens en dur est plus compliqué dans tous les cas, car ce ne sont pas des fichiers, mais des entrées supplémentaires pour accéder aux mêmes données.

- définir les limites dans la prise en compte des droits linux. Bien sûr, on peut se dire: quand je n'ai pas assez de droits, je donne le mot de passe pour les avoir tous. Mais c'est un peu simpliste, et il est dommage de ne pas comprendre un peu plus comment ça marche. Qu'est-ce qu'un utilisateur "normal" a le droit de copier et qu'est-ce qui se passe quand il va au delà?

Vous aurez aussi à résoudre des problèmes d'encodage de noms de fichier.

Bref, c'est a priori un problème plus complexe qu'on ne le pense au départ, mais c'est très intéressant et très formateur.

Sans faire partie de votre équipe projet, je peux au moins vous aider dans 2 domaines:

1- mon programme de sauvegarde sélective n'est pas assez fini pour que je publie, mais il marche, et je le mettrai sans problème à votre disposition. Il contient des fonctions assez robustes et des principes algorithmiques qui fonctionnent bien (copie récursive, effacement récursif, test de sélection/exclusion, p. ex.).

-2 je peux vous aider pour la gestion des droits Linux (hors ACL). J'avais fait une petite étude sur le sujet, elle est ici:

http://linux.jpvweb.com/mesrecetteslinux/droits_linux

Bon courage!

Tyrtamos

[pour Linux, je travaille surtout sur Opensuse, mais je connais aussi Ubuntu et Debian]

[nardo47]

Salut,

- est-ce que Python vous semble approprié pour un tel projet?

Oui, mais Python me semble approprié pour tous les projets (sauf de l'embarqué).
Il faut savoir que Python n'est pas le + rapide des langages, mais les possibilités d'optimisation sont multiples:

• ne pas succomber au syndrome "not invented here", c'est-à-dire se reposer sur des lib déjà écrites si elles remplissent un besoin (et Guido sait qu'il en existe une palanquée !);
• écrire de meilleurs algorithmes (par forcément évident, mais c'est en forgeant... );
• réécrire certaines parties délicates au niveau du temps d'exécution en C.

Je crois (et j'ai eu pas mal de retours qui confirment cette croyance) que la facilité et la rapidité d'écriture d'un programme en Python permettra d'avoir assez vite quelque chose de fonctionnel, qui pourra être optimisé après (même si cela veut dire réécrire une partie (+ ou - grosse) du code en C).

Quoiqu'il en soit, l'optimisation doit être en dernier dans ta liste de priorités.

Make it work, then make it right, then make it fast!

- est-ce que vous pensez que la difficulté du projet est abordable pour de jeunes étudiants motivés mais n'ayant pas forcément beaucoup de temps à consacrer de façon régulière sur un tel projet?

La majorité (mais je m'avance peut-être, là) des développeurs de logiciels libres gagnent rarement leur vie avec leurs logiciels (et ils ont aussi une vie personnelle). Si vous êtes assez motivés pour aller jusqu'au bout du projet, ça vaut le coup !

je ne vois pas l'intérêt de le rendre multiplateforme.

Ne soyons donc pas sectaires !

Et elle ne tournerait donc que sur les plateformes Linux.

Et non ! Python est assez portable pour que ton programme puisse tourner sur + de plateformes que tu ne l'avais prévu (il faudra juste penser à gérer l'histoire de la copie vers les dossiers root, ça risque d'être rigolo sous Windows !).
En utilisant bien les libs de Python (je pense notamment au module os.path qui permet de ne pas soucier des séparateurs de dossier, de chemin, etc.), le code est normalement exécutable sous Windows et sous Linux sans problème !
Le seul problème qui se posera pour la portabilité sera les éventuels bouts de code C qui auront été créé pour des raisons de perf.
D'ailleurs, je ne sais pas pour GTK, mais Tkinter et wxPython sont portables sur plusieurs plateformes (Tk car il vient avec Python et wx car il est dispo sur une foultitude de plateformes).

Je ne pense pas que cela soit vraiment une bonne idée de faire un logiciel de ce genre en Java

Et pourquoi pas ? Si le dév a fait du Java pendant des années, qu'il connait bien les libs tierce-partie, qu'il sait optimiser son travail avec Java.
Re-ne soyons donc pas sectaires.

qui se veut de plus multiplateforme et donc écrit en Java.

Une induction un peu hâtive. Python dispose aussi d'une machine virtuelle, et est donc très portable. La même chose pour Ruby. Et Perl et PHP sont portables aussi.

Et de plus cela ne me semble pas très optimisé.

D'accord, le logiciel en Java n'est peut-être pas optimisé, mais il ne faut pas croire que Java soit lent.

Bon, vu qu'on n'est pas sur le forum Java, j'arrête là, on risque de croire que je suis un agent infiltré !

Si tu connais Python (ou si tu ne connais pas d'autre langage de prog), je te le conseille définitivement, le gain de productivité compense largement les perfs, qui sont de + compensables par les moyens dont j'ai parlé + haut.

Bon courage à vous !

[PauseKawa]

Bonjour,

Et non ! Python est assez portable pour que ton programme puisse tourner sur + de plateformes que tu ne l'avais prévu (il faudra juste penser à gérer l'histoire de la copie vers les dossiers root, ça risque d'être rigolo sous Windows !).
En utilisant bien les libs de Python (je pense notamment au module os.path qui permet de ne pas soucier des séparateurs de dossier, de chemin, etc.), le code est normalement exécutable sous Windows et sous Linux sans problème !
D'ailleurs, je ne sais pas pour GTK, mais Tkinter et wxPython sont portables sur plusieurs plateformes (Tk car il vient avec Python et wx car il est dispo sur une foultitude de plateformes).

+1
J'avais fais mumuse il y a un moment avec un gestionnaire de fichier en python/Tkinter et avec os.path et shutil c'est largement portable pour ce qui est des copies/déplacements.
C'est dommage de se priver de cela.

@+

[tyrtamos]

Bonjour,

Juste une petite remarque concernant le caractère multiplateforme (windows/linux/mac): il est inévitable d'avoir des particularités dans la gestion des droits (test avec sys.platform).

C'est plus clair et plus "carré" avec Linux et mac, mais avec Windows (vista et 7), il y a des attributs qui nécessitent un traitement spécifique (attributs caché, système, ...) et certaines règles qui sont mystérieuses et très mal expliquées (certaines actions sont interdites, même sous "administrateur"). Je n'ai pas évoqué ce pb plus haut parce que windows ne faisait pas partie du projet.

A part ces particularités de droits, il est effectivement très facile de faire du multiplateforme.

Pour la bibliothèque graphique, je suggère tkinter. Avec la plupart des linux courants, Python est déjà installé par défaut, et le paquet tkinter est disponible facilement.

Tyrtamos

[Sherwood51]

Bonjour à tous,

tout d'abord, merci pour ces réponses encourageantes!

@tyrtamos: merci beaucoup pour ces précisions et la mise à disposition de ton étude et de ton programme de sauvegarde sélective! C'est vraiment encourageant pour nous.

Pour des raisons de complexité, dans un premier temps en tout cas, le programme ne tournera que sur Linux. Ce n'est pas pour être sectaire nardo47 mais pour une question de taille du projet et de complexité. Si le projet avance bien et aboutit à quelque chose de pleinement utilisable, alors pourquoi pas envisager un portage vers d'autres plateformes par la suite mais ce n'est pas un objectif. Quoiqu'il en soit nardo47, merci beaucoup pour ces précieux encouragements, informations et conseils.

Pour la bibliothèque graphique c'est pas vraiment fixé encore. A voir.

On va donc maintenant établir un cahier des charges précis et mon ami devrait pouvoir remettre en ligne son site qui pourra héberger le projet.

[nardo47]

Pour des raisons de complexité, dans un premier temps en tout cas, le programme ne tournera que sur Linux. Ce n'est pas pour être sectaire nardo47.

Ok, la partie "sectaire" était dite avec ironie. Et je vais reformuler mon discours :
Le fait d'utiliser Python te permettra, lorsque le moment sera venu, de porter facilement (disons, moins douloureusement qu'avec d'autres langages qui sont + bas niveau) sur d'autres plate-formes.
(A noter que c'est le cas pour tout langage avec une JVM, donc Java & Ruby... Prolog aussi, maintenant que j'y pense, mais pour faire un copieur en Prolog, faut s'accrocher )

PauseKawa a raison de citer shutil, c'est un module fantastique que j'ai découvert récemment, mais que je n'ai pas encore l'habitude d'utiliser (et donc de citer), et qui va t'aider grandement pour ton projet.

Re-bon courage