Forum Programmation.python Python mal installé

Posté par  . Licence CC By‑SA.
Étiquettes :
1
11
mar.
2025

Bonjour et déjà merci pour votre aide.
Par ailleurs, je ne sais pas si je suis au bon endroit pour poser ma question… si pas mes excuses et merci de me donner des pistes de réflexions.
Voici donc mon problème : je pense que mon logiciel Python est installé au mauvais endroit voici le path ~/.cache/activestate/bin
Quand je veux utiliser pip install pour ajouter des bibliothèques, le système m'envoie des erreurs.
Quand je veux passer à la version python3.13 et que je lui demande de l'installer dans un répertoire :~/PYTHON$, je me retrouve avec la version 3.10.

J'avoue que je suis un peu perdu Pourquoi mon programme est-il dans un répertoire caché (/.cache) serait-ce la cause du problème et comment puis-je disposer de la dernière version de Python et pouvoir utiliser les extensions via pip ?

Pour information, je suis sous UBUNTU 24.4 et je programme en Python via VSCode

  • # droits

    Posté par  . Évalué à 3 (+1/-0).

    Les paquets Python pip doivent être installés avec droits root, le mieux dans un environnement "virtuel" pour ne pas semer le bazar.

    Essentiellement, un environnement virtuel imite une installation complète de Python et de tous les modules souhaités sans interférer avec le système sur lequel l'application pourrait s'exécuter.
    https://wiki.archlinux.org/title/Python#Third-party_packages
    https://wiki.archlinux.org/title/Python_(Fran%C3%A7ais)/Virtual_environment_(Fran%C3%A7ais)

    • [^] # Re: droits

      Posté par  (site web personnel) . Évalué à 2 (+0/-0).

      Les paquets Python pip doivent être installés avec droits root

      ?????

      Ça dépend franchement de ce que doit faire l'application (et autant que possible on évite).

      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

      • [^] # Re: droits

        Posté par  . Évalué à 2 (+0/-0).

        et autant que possible on évite

        Mon commentaire parlait de droits root dans le cadre d'un environnement virtuel, c'est d'ailleurs ce qui est préconisé dans la doc de Arch

        $ virtualenv envname
$ source envname/bin/activate
(envname) $
(envname) $ deactivate

        • [^] # Re: droits

          Posté par  (site web personnel) . Évalué à 2 (+0/-0).

          Le côté virtuel des environnements Python est juste lié… à Python / ses paquets. L'exécution se fait avec le compte de l'utilisateur, par défaut il n'y a pas d'isolation comme dans une VM par exemple, donc si ça tourne avec un compte utilsateur root, ça a les droit root. Je ne vois pas ce que signifie «droits root dans le cadre d'un environnement virtuel».

          Sinon je me gourre car il y a eu une grosse évolution côté sécurité dans les environnements Python, que j'aurais raté.

          Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

          • [^] # Re: droits

            Posté par  . Évalué à 2 (+0/-0).

            j'ai lu quelque part que l'intégration des paquets python pip avec les paquets python installés par la distribution, Arch en ce qui me concerne, peut poser des problèmes s'ils sont installés en tant qu'utilisateur.
            Concernant la doc de python-pipenv, tout est en root
            https://pipenv.pypa.io/en/latest/commands.html

            $ pipenv install <package_name>

            • [^] # Re: droits

              Posté par  (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 18 mars 2025 à 20:00.

              j'ai lu quelque part que l'intégration des paquets python pip avec les paquets python installés par la distribution, Arch en ce qui me concerne, peut poser des problèmes s'ils sont installés en tant qu'utilisateur.

              Oui, et c'est général pour toutes les distributions Python, car ils peuvent prendre la priorité par rapport aux paquets de la distro et, en cas de version incompatible, casser le fonctionnement des outils Python de la distro (j'ai déjà eu un collègue chez qui j'ai débogué ce problème, avec un paquet dans .local/lib/pythonX.Y/site-packages).
              D'où le conseil d'impérativement utiliser un environnement Python dédié lorsqu'on a des paquets qui doivent être installés hors du gestionnaire de paquets. Et le conseil d'utiliser python3 -m pip install XXX est lié à ça : utiliser le Python de l'environnement virtuel actif pour faire les install dans cet environnement.

              pipenv fait ça avec son option --python=…. Perso je préfère avoir un environnement "activé" (avec un joli préfixe sur le prompt) et qu'après les commandes d'installation soient systématiquement dans cet environnement.

              Et je ne comprend pas «Concernant la doc de python-pipenv, tout est en root» — si ça a été installé via le gestionnaire de paquets, c'est généralement propriété de root, mais ça tourne avec le droit de l'utilisateur (sauf bit suid). Mais il n'y a pas de nécessité que pipenv appartienne à root pour créer un environnement virtuel pour l'utilisateur.

              Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

  • # Astuce

    Posté par  (site web personnel) . Évalué à 5 (+3/-0).

    Ne jamais utiliser pip mais toujours python3 -m pip. Au moins, tu sais quel python pip utilise.
    Ensuite, il y a deux cas, soit tu veux installer un binaire « comme un autre » dans ce cas, je te conseille de regarder pipx (qui va installer ton binaire dans ton path en isolant les libs Python dans un environnement dédié à ce binaire), soit tu veux un environnement de développement pour un projet. Dans ce cas, regarde poetry ou virtualenv.

  • # virtual env

    Posté par  . Évalué à 2 (+0/-0).

    En gros, dans un terminal

    mkdir ~/mon_super_logiciel
cd ~/mon_super_logiciel
python3 -m venv .venv
. .venv/bin/activate
pip install -r requirements.txt
python mon_super_logiciel.py
codium .   # ouvrir vscode dans le répertoire projet

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.