Travailler sur une lib externe à votre projet proprement en Python. Quand on a une lib externe en dépendance à son projet, on veut être capable de l’importer MAIS pouvoir en modifier le code.
L’installer avec pip ou python setup.py install va copier le code dans le dossier site-packages et ce n’est pas ce que l’on veut car ça oblige à refaire l’installation à chaque modif. Le mettre dans un dossier “libs” qu’on ajoute au PYTHON PATH ou pire, ajouter chaque dépendance au PYTHON PATH n’est pas une solution qu’on est fier d’exhiber au hackerspace du coin. On s’en remet donc généralement à un symlink, sans savoir qu’il existe en fait un outil fait pour ça : Cette commande va ajouter des entrées spéciales dans des fichiers placés dans site-packages qui vont vous permettre d’utiliser votre lib comme si elle était installée. Mais en vérité il va chercher le code dans votre dossier de dev, donc si vous modifiez le code, vous avez toujours la version de votre lib la plus fraîche.
Une fois qu’on a une lib stable, on peut retirer ce lien avec : Par : Sans soucis. Ex : Les imports en Python. Je suis fan de carmina burrana depuis l’age de 12 ans, alors pourquoi pas O Fortuna comme musique d’ambiance : Les imports, c’était fastoche.
Vous étiez dans votre petit programme, et pour importer un module de la lib standard, vous faisiez: Par exemple : Et pour importer une classe ou une fonction de cette lib, vous faisiez : from module import fonction from module import Classe from hashlib import md5 from xml.etree import Element Parfois, c’était un peu plus compliqué, mais ça allait encore. From package.sous_package import module from xml.sax import saxutils Mais ça allait encore. Et puis un jour vous avez du écrire votre propre module. Vous avez donc décidé de vous remettre à PHP, au moins le include utilise les chemins de fichiers, et ça, c’est facile.
Sous le capot Quand vous utilisez import, sous le capot Python utilise le fonction __import__. >>> os = __import__('os') >>> os.path.join('s', 'ton', 'mon', 'g') u's/ton/mon/g' Mais pour vous, seule l’étape 1 est importante à comprendre. A Note on Python Paths. This time I decided to share some knowledge about Python paths which seemed a little bit confusing to me in the beginning of diving into Python.
I am working with Django in different platforms like Mac OS X, Windows, and Linux, therefore the common patterns how to activate new python modules in all of those environments should be familiar to me. Python modules are either *.py files or directories containing __init__.py . When defining paths to python modules, you will usually need to deal with the latter ones. A module is meant to be under python path if you can run python and import that module. For example, if you can run the following, then django is under your python path. python >>> import django Stay tuned to get deeper into python paths. Installing modules If a module is installable, usually all you need to do is to extract its setup directory, cd to it, and run. Using .pth files for Python development. Python's site module is responsible for setting up the interpreter's environment upon startup.
One of the things it does during startup is scan your site directories (typically just site-packages , but framework builds for Mac OS X have an additional undocumented default location) for .pth files. .pth files are used to add additional locations sys.path , and they are typically created by distutils setup scripts that use the (still undocumented) extra_path argument. .pth files are a great alternative to using the PYTHONPATH environment variable: You don't have to screw with your environment (which can be difficult on Mac OS X and Windows).
The effect is localized to a particular Python installation. You can toggle their usage simply by moving them around on the filesystem. py2app.pth # /Users/bob/src/py2app is a svn checkout of: # # /Users/bob/src/py2app/src docutils.pth PyObjC.pth ctypes.pth This is somewhat inconvenient because: There are two features I wish that the site module had: