Discussion :

[marietar]

Bonjour
je viens d'installer ubuntu 22.04 et je souhaite faire du pyhton, je débute depuis quelques semaines.

si j'installe la derniere MAJ de pyhton, est-ce que ca ecrase ma version actuelle livrée avec Ubuntu et ou ca en crée une nouvelle?

Aussi, je lis qu'il faut éviter d'installer des paquets sur note environnement de base et toujours travailler sur des environnements virtuels dans lesquels on installe uniquement les paquets ou librairie qu'on veut pour notre application qu'on va développer en pyhton.
Vous recommandez cette stratégie?

ou bien je fais juste des pip install sans me prendre la tete??

merci

[wiztricks]

Vous recommandez cette stratégie?

Yes.
A partir du moment où le système utilise aussi Python, pourquoi risquer de le rendre inutilisable alors que vous pouvez mettre à jour un environnement virtuel (sans passer par root).

si j'installe la derniere MAJ de pyhton, est-ce que ca ecrase ma version actuelle livrée avec Ubuntu et ou ca en crée une nouvelle?

Tout dépend du kit d'installation... qui est réalisé par des développeurs de la distribution Linux et qui ont le choix.
Après vous pouvez compiler Python à partir des sources et l'installer dans votre répertoire utilisateur: pas de collision avec le python système.

- W

[Sve@r]

Bonjour

si j'installe la derniere MAJ de pyhton, est-ce que ca ecrase ma version actuelle livrée avec Ubuntu et ou ca en crée une nouvelle?

Si tu utilises le gestionnaire de paquet Ubuntu (apt-get ou aptitude) ça met à jour. Si tu télécharges les sources et que tu compiles, ça en crée une nouvelle (qui peut être "en plus" ou "à la place" de l'acienne, ça dépend de comment tu installes la version compilée).

Aussi, je lis qu'il faut éviter d'installer des paquets sur note environnement de base et toujours travailler sur des environnements virtuels dans lesquels on installe uniquement les paquets ou librairie qu'on veut pour notre application qu'on va développer en pyhton.
Vous recommandez cette stratégie?

Ca c'est quand on est en mode professionnel, qu'on développe plusieurs projets. Chaque projet possède son propre environnement pour ne pas entrer en collision avec d'autres libs dans d'autres projets.
Quand on débute, on n'en est pas là.

ou bien je fais juste des pip install sans me prendre la tete??

Tu fais sudo apt-get install sans te prendre la tête. Mais à mon avis, les libs installées par défaut sont déjà bien suffisantes pour débuter.

[marco056]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sudo apt install

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sudo pip install

Pour les librairies à ajouter, effectivement, il en manque qqs unes suivant tes besoins.
Pour ma part, je travaille sur spyder.

[binarygirl]

Aussi, je lis qu'il faut éviter d'installer des paquets sur note environnement de base et toujours travailler sur des environnements virtuels dans lesquels on installe uniquement les paquets ou librairie qu'on veut pour notre application qu'on va développer en pyhton.
Vous recommandez cette stratégie?

De manière générale: oui.
Créer des venv ça bouffe quand même de la place, pas tant que ça mais c'est à chaque fois un environnement Python complet. Donc ça a un côté "wasteful".
Je développe souvent sur des VM avec des snapshots, donc je n'hésite pas à installer des libs directement au niveau de l'OS via les packages fournis par la distro. Je ne pense avoir eu de soucis jusqu'à présent.
De toute façon, quand on distribue l'application on fournit un fichier requirements (ou équivalent en Poetry) et l'utilisateur final peut très bien décider de tout installer dans un venv ou non de son côté.

Mais c'est vrai que dans certains cas on peut avoir besoin de figer certaines versions de packages, parfois pour contourner des bugs connus, et on peut éventuellement se retrouver avec des conflits ou interdépendances, c'est le problème que Poetry se charge de résoudre. Il y a aussi des utilitaires systèmes qui sont écrits écrits en Python et le fait d'installer certaines libs, ou même mettre à jour Python (par ex. vers 3.10) peut effectivement les casser parfois. J'ai vu ça sous Arch Linux à l'occasion, mais en général ça s'arrange facilement, ou un fix est livré après quelques jours.

Et si l'application est "containerisée", par exemple en Docker, alors le besoin d'un venv est encore moins impératif.

[papajoker]

bonjour

La pile python pour du développement est relativement compliquée, mais en tout cas, on oublie les paquets de notre linux (si de véritables* projets).
*Si le but de tes projets est de véritablement tourner sur ta machine, je me doute que tu ne vas pas activer un environnement virtuel à chaque fois que tu vas l'utiliser.

Existes plusieurs outils, par exemple :
- pyenv pour installer plusieurs versions de python
- venv, poetry pour manager les bibliothèques
A toi de faire des recherches

[VinsS]

Salut,

Il ne faut JAMAIS changer la version système de Python dans un environnement Linux, diverses applications ne tourneront plus.

Maintenant si tu as besoin de tester tes codes sous diverses versions de Python alors tu crées des environnements virtuels pour cela.

J'ai publié un HOWTO à ce sujet:
https://www.developpez.net/forums/d1...ls-sous-linux/

[Pyramidev]

Vous recommandez cette stratégie?

Oui. C'est vital. Sinon, plus tard, le jour où on essaie de désinstaller des paquets du Python de l'OS, on peut avoir de mauvaises surprises.

D'ailleurs, si la documentation d'un exécutable (par exemple jello) conseille de l'installer avec pip, c'est généralement une meilleure idée de l'installer avec pipx.

Sur Linux, un bon moyen de débuter en Python est d'utiliser le trio venv + pip + make. À ce sujet, voici un article qui est pas trop mal quand on débute : Creating a Python Makefile.

Cet article propose un code en 4 fichiers :

api.py :

Code Python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
import requests
 
def get_fact(number):
    url = "http://numbersapi.com/{}".format(number)
 
    r = requests.get(url)
    if r.status_code == 200:
        print(r.text)
    else:
        print("An error occurred, code={}".format(r.status_code))

app.py :

Code Python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
import api
 
api.get_fact(input("Enter a number: "))

requirements.txt :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

requests

Makefile :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
VENV = venv
PYTHON = $(VENV)/bin/python3
PIP = $(VENV)/bin/pip
 
.PHONY: run clean
 
run: $(VENV)/bin/activate
	$(PYTHON) app.py
 
$(VENV)/bin/activate: requirements.txt
	python3 -m venv $(VENV)
	$(PIP) install -r requirements.txt
 
clean:
	rm -rf __pycache__
	rm -rf $(VENV)

Dans le dossier contenant ces 4 fichiers, il suffit de lancer make ou make run pour créer l'environnement virtuel s'il n'existe pas déjà, puis lancer directement app.py depuis l'environnement virtuel. make clean permet de supprimer l'environnement virtuel et le dossier __pycache__.

C'est juste un début.

Dans la suite de l'apprentissage, il faudra aussi ajouter le reformatage du code (ex : black et isort), les linters (ex : pylint) et les tests automatisés.

Il faudra aussi pourvoir choisir la version de Python en fonction du projet et utiliser des outils plus avancés que pip. Mais, en ce moment, l'écosystème du packaging en Python ressemble encore à une jungle, donc il n'y a pas vraiment de solution standard et les solutions les plus populaires changent avec le temps. Personnellement, j'aime bien utiliser une combinaison de pyenv et pip-tools, mais il existe aussi Poetry, conda et beaucoup d'autres. Mais, dans tous les cas, en Python, il est utile d'être à l'aise avec venv et pip avant de passer à plus compliqué.

[marietar]

merci pour les liens

[marietar]

re
je ne comprends pas trop le makefile
dans le lien que ut me donnes : https://earthly.dev/blog/python-makefile/

ca commence par dire de créer un makefile avec ces lignes:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
run:
	python3 app.py

puis quand je fais make run dans la console, j'ai le code qui s'execute

pius le site me dit d'ajouter une nouvelle ligne pour installer le paquet request
puis d'ajouter une ligne pour nettoyer le dossier en supprimant le dossier __pycahce__

dans ubuntu 22.04, j'ai la paquet request qui est déjà installé, je vais donc juste supprimer le dossier __pycache__

mais quand je fais make

j'ai donc ce makefile:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
clean:
    rm -rf __pycache__
 
run:
	python3 app.py

mais quand je fais make run dans la console, j'ai cette erreur:
makefile:2: *** séparateur manquant. Arrêt.

que dois-je faire?

[Pyramidev]

mais quand je fais make run dans la console, j'ai cette erreur:
makefile:2: *** séparateur manquant. Arrêt.

que dois-je faire?

Il faut remplacer les 4 espaces par une tabulation. C'est une bizarrerie de make.

Note that there are tabs before the recipe lists. Anything other than tabs will result in an error.

Il y a un problème de mise en page du code de l'article. J'ai dû aussi remplacer à la main ces espaces par des tabulations.

[tyrtamos]

Bonjour

Je ne savais pas qu'il pouvait exister autant de pratiques différentes sur le sujet! Alors, j'ajoute la mienne :

Sous Linux (mint pour moi):

- j'utilise toujours Synaptic pour ajouter les paquets Python, tant que ceux qui m'intéressent existent. Sinon pip.

- je suis plutôt favorable aux environnements virtuels (venv) pour éviter de "polluer" le Python installé par défaut, celui-ci étant utilisé par l'OS.

- je ne conseille pas d'ajouter un autre Python à celui par défaut, sauf si le Linux qu'on a en est encore à Python v2. A part peut-être avec pyenv (ex: https://blog.stephane-robert.info/po...-pyenv-pipenv/)?

- je ne vois pas d'utilité à compiler Python à partir des sources, sauf si c'est pour apprendre. Mais il est vrai que les Linux ont souvent un petit retard de version du Python installé. Alors, si on veut vraiment la dernière version... Mais dans ce cas, les modules externes dont on a besoin ont souvent un retard de version aussi, et il faudra faire très attention aux conditions d'installation en plus du Python installé! Ce n'est vraiment pas une solution pour débutant!

[marietar]

Bonjour

Je ne savais pas qu'il pouvait exister autant de pratiques différentes sur le sujet! Alors, j'ajoute la mienne :


- je ne vois pas d'utilité à compiler Python à partir des sources, sauf si c'est pour apprendre. Mais il est vrai que les Linux ont souvent un petit retard de version du Python installé. Alors, si on veut vraiment la dernière version... Mais dans ce cas, les modules externes dont on a besoin ont souvent un retard de version aussi, et il faudra faire très attention aux conditions d'installation en plus du Python installé! Ce n'est vraiment pas une solution pour débutant!

ca veut dire quoi compiler Python à partir des sources??
ca veut dire utilise le makefile?

je viens de decouvrir le makefile et je trouve ca très pratique

[tyrtamos]

ca veut dire quoi compiler Python à partir des sources??
ca veut dire utilise le makefile?

Les sources de Python sont écrits en C. Exemple pour la version 3.10.9:
https://www.python.org/ftp/python/3....hon-3.10.9.tgz

Compiler Python à partir des sources, c'est donc faire la compilation complète du C en code natif pour obtenir l'interpréteur Python.

[Sve@r]

ca veut dire quoi compiler Python à partir des sources??

Les programmes Unix/Linux sont des programmes écrits généralement en C^*. Et étant dans le domaine public, ils sont donc disponibles en tant que "source" (tu peux télécharger/voir/modifier le code d'origine). Et ensuite, pour les rendre exécutables, il faut les compiler.

(*) enfin ça pourrait changer dans le futur car il est plus ou moins question de remplacer le C par rust

ca veut dire utilise le makefile?

Ce n'est pas une obligation mais comme tu le soulignes, c'est un outil assez pratique donc généralement induit.

[wiztricks]

- je ne vois pas d'utilité à compiler Python à partir des sources, sauf si c'est pour apprendre. Mais il est vrai que les Linux ont souvent un petit retard de version du Python installé. Alors, si on veut vraiment la dernière version..

Il y a des boîtes qui vont vers Linux pour y installer des applications et ne toucher à rien tant que ce n'est pas nécessaire. Sauf que parfois il faut y ajouter de nouvelles applications en évitant de mettre à jour l'environnement système.

Et c'est là qu'on a "conflit" entre des machines de développements qui tournent des versions récentes et la cible - sous versions anciennes... Est-ce qu'on peut utiliser le python existant ou sera-t-il jouable d'ajouter une version récente à côté? Que faire côté bibliothèques?
A ce moment là, on repart des sources et on teste (et ça ne prend pas des semaines).

note: J'entends que pour certain l'idéal est de mettre à jour régulièrement... mais dans la vraie vie, c'est pas toujours un bon choix.

- W

[marietar]

j'ai un doute sur l'installation de paquets dans un env virtuel.

je crée mon env virtuel avec cette commande: python -m venv venv
ensuite je dois l'activer puis installer les paquets?
ou je peux installer les paquets tout de suite après avoir créé l'env virtuel?

[Sve@r]

ou je peux installer les paquets tout de suite après avoir créé l'env virtuel?

Non. Puisque tu as créé un environnement (tout comme tu aurais pu en créer 50), il te faut l'activer (ne serait-ce que pour pouvoir dire dans lequel des 50 tu veux te positionner)
cd venv; source bin/activate et là tu peux installer les paquets qui seront donc installés dans le Python du dossier "venv" (que tu aurais pu quand-même nommer autrement)

VinsS avait déjà tout écrit à ce propos et t'avait donné les liens.

[Pyramidev]

je crée mon env virtuel avec cette commande: python -m venv venv
ensuite je dois l'activer puis installer les paquets?
ou je peux installer les paquets tout de suite après avoir créé l'env virtuel?

venv/bin/activate est un script Bash qui, entre autres, ajoute le chemin venv/bin en tête de la variable d'environnement PATH et crée une fonction deactivate qui permet d'annuler les changements.

Dans le terminal, si tu lances source venv/bin/activate alors, quand tu lanceras une commande python (respectivement pip), l'OS comprendra qu'il s'agira de venv/bin/python (respectivement venv/bin/pip).

Attention cependant au cas du Makefile. Par défaut, make exécute chaque ligne dans un sous-shell séparé. Du coup, si tu écris, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
run: venv/bin/activate
	source venv/bin/activate
	python app.py

alors make run va exécuter les commandes source venv/bin/activate et python app.py dans deux sous-shells différents et le python exécuté ne sera pas venv/bin/python.

Du coup, dans un Makefile, il vaut mieux directement écrire quelque chose comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
run: venv/bin/activate
	venv/bin/python app.py

Anecdote : À une époque, j'appelais directement venv/bin/python depuis des scripts Python. Avec le Python de l'OS, j'exécutais des commandes avec le Python de l'environnement virtuel avec des appels du genre subprocess.check_call(("venv/bin/python", "-m", "pylint", "my_project")). Ensuite, j'ai trouvé que les Makefile étaient plus pratiques.

venv/bin/activate, c'est un utilitaire pour taper plus facilement des commandes depuis le terminal.

dossier "venv" (que tu aurais pu quand-même nommer autrement)

En fait, "venv" est un bon nom de dossier virtuel quand on le crée dans le dossier du projet. Un avantage que j'ai découvert est que, avec PyCharm, quand on ouvre un dossier qui contient déjà un sous-dossier "venv", PyCharm comprend tout de suite que c'est l'environnement virtuel et se configure tout seul, sans action manuelle, en choisissant venv/bin/python comme étant l'interpréteur Python du projet. Et quand on ouvre un terminal depuis PyCharm, il active directement l'environnement virtuel. C'est plutôt pratique.

[VinsS]

j'ai un doute sur l'installation de paquets dans un env virtuel.

je crée mon env virtuel avec cette commande: python -m venv venv
ensuite je dois l'activer puis installer les paquets?
ou je peux installer les paquets tout de suite après avoir créé l'env virtuel?

Oui, il faut toujours l'activer pour l'utiliser et donc pour y installer des nouveaux modules.