Closed alhyss closed 2 years ago
Leslie, C'est ce que j'avais fait pour l'outil "POC_INSTAL_BIBLI" Je suis dessus pour regarder déjà mon proxy avec pypac maintenant que je sais faire avec les biblis locales. Mais bon encore des recherches et des test, mais le fonctionnement pour le moment est satisfaisant
Tant mieux si tu maîtrises déjà les fichiers de dépendances :)
D'accord avec toi sur le fait que c'est opérationnel actuellement, et d'ailleurs je ne pense pas qu'il faille perdre de temps à se préoccuper du proxy pour le moment, vu que ça fonctionne déjà. Le seul défaut est que le plugin fait quelques Mo de plus, mais ce n'est vraiment pas dramatique.
Ce que j'évoque ci-avant me semble plus important, même si ce n'est pas urgent, car le système actuel ne lance les installations que si l'import de RDFLib échoue. Il ne permet réellement pas de gérer les mises à jour des bibliothèques, seulement l'installation initiale.
La dépendances DUKPY nécessaire à PyPac n'existe pas pour python 3.9 C'est un bon exemple pour montrer qu'entre : Les versions des bibliothèques, leurs dépendances, et les versions de python, ce n'est pas simple
Après investigation Installation en local A tester, ça semble OK
Changement de fond :
Pour toutes autres bibliothèques
Excellent ! Donc ça marche vraiment une fois réglé le problème des chemins ! :)
Si je comprends bien, pour que ça continue à fonctionner avec le système actuel - qui déclenche l'import des bibliothèques pendant le chargement de mon module plume.rdf.rdflib
quand from rdflib.graph import Graph
échoue -, il faut au moins que je modifie plume.rdf.rdflib
en remplaçant :
from plume.bibli_install.bibli_install import manageLibrary
par :
from plume.bibli_install import manageLibrary
Ensuite il faudra réfléchir à une méthode propre pour mettre à jour RDFLib s'il y a lieu. À ce sujet, j'avais en tête des choses compliquées à base de contrôle de version, mais est-ce qu'on ne pourrait pas juste faire quelque chose de ce genre :
QGIS3.ini
une variable qui prendrait par exemple comme valeur le numéro de la version courante de Plume, ou n'importe quelle valeur qu'on incrémenterait à chaque nouvelle version ;plume.bibli_install.manageLibrary
soit exécutée systématiquement (et plus seulement quand l'import de RDFLib échoue dans le module plume.rdf.dflib
) ;plume.bibli_install.manageLibrary
va lire la variable susmentionnée. Si la variable existe et que sa valeur correspond déjà à la version courante, elle s'arrête là. Sinon, elle procède à l'installation / la mise à jour des bibliothèques, puis met à jour la variable avec le bon numéro de version.De cette façon, l'installation ou mise à jour des bibliothèques devrait se faire à l'installation et à chaque mise à jour de Plume (ou plus précisément à la première activation post installation/mise à jour) comme on peut le souhaiter, sans pour autant se déclencher à chaque ouverture du plugin, ce qui serait vraiment gênant.
Est-ce que ça te semble une bonne idée ?
Accessoirement, nous n'en aurions a priori pas besoin dans ce cas, mais une méthode qui pourrait nous servir s'il fallait tester la disponibilité d'un module sans passer par un try
/except
:
>>> from importlib.util import find_spec
>>> find_spec('rdflib')
ModuleSpec(name='rdflib', loader=<_frozen_importlib_external.SourceFileLoader object at 0x000001ECE7C770F0>, origin='C:\\Users\\me\\AppData\\Roaming\\Python\\Python37\\site-packages\\rdflib\\__init__.py', submodule_search_locations=['C:\\Users\\me\\AppData\\Roaming\\Python\\Python37\\site-packages\\rdflib'])
>>> find_spec('truc')
from plume.bibli_install import manageLibrary
"Donc ça marche vraiment une fois réglé le problème des chemins ! :)" Quels chemins posent pb maintenant, ça ne te va pas ?
gérer dans le fichier QGIS3.ini
Donc, on prend l'option de mettre à jour si nouvelle version de Plume avec ce système
dans le QGIS3.INI
"Donc ça marche vraiment une fois réglé le problème des chemins ! :)" Quels chemins posent pb maintenant, ça ne te va pas ?
Rhha, pardon, c'est encore moi qui ne suis pas claire ! Il n'y a rien qui pose problème pour autant que je puisse voir. J'étais juste contente de constater que tu as trouvé comment écrire les chemins et que maintenant tout fonctionne exactement comme on le souhaitait ! (y compris la mise à jour, donc, c'est parfait !)
Par contre, laisse-moi faire la modif dans mon module, si ça ne t'embête pas trop. Je la publierai sur le Git dans la foulée de la tienne pour qu'on garde quelque chose de cohérent. C'était pour ça que je te demandais de me confirmer ce qu'il y avait à changer de mon côté.
Et oui, effectivement, le système qu'on évoque déclenchera la mise à jour à chaque nouvelle version de Plume, même si nous n'avons changé aucun des fichiers wheel. Mais ça me semble acceptable ?
Ok, c'est toi qui mettra à jour rdflib.py Mais il faut se coordonner.
Deux objectifs :
try
/except
.Une première piste serait d'utiliser la commande
list
depip
pour lister les packages installés et leurs versions. Il y a une option--format=json
qui permettrait de récupérer ça sous une forme aisément exploitable. Il faudrait bien sûr avoir une liste des dépendances avec laquelle comparer ça.Mais, plutôt que de réinventer la poudre, on pourrait tenter de faire ça avec un fichier de dépendances
requirement.txt
et il n'y aurait ensuite besoin que de lancer une commandepip install -r requirement.txt
(avec le bon chemin pour le fichier, évidemment, et je ne sais pas s'il faut un--upgrade
dans ce cas). Si je comprends bien, pour n'aller chercher les installeurs qu'en local, il faut l'option--no-index
et utiliser--find-links
pour spécifier le répertoire contenant les fichiers wheel.Syntaxe pour le fichier de dépendances : https://pip.pypa.io/en/stable/reference/requirements-file-format/.
Qu'en penses-tu @WREATCHED ?
Je flèche sur la v1.0 pour le moment, mais nous risquons d'être confrontés à la question de la mise à jour des bibliothèques avant ça.