Manière standard d'incorporer la version dans un package python?

Existe-t-il un moyen standard d'associer une chaîne de version à un package python de telle manière que je puisse faire ce qui suit?

import foo
print foo.version

J'imagine qu'il existe un moyen de récupérer ces données sans aucun codage supplémentaire, car les chaînes mineures / majeures sont setup.pydéjà spécifiées dans . Une solution alternative que j'ai trouvée devait avoir import __version__dans mon foo/__init__.pyet ensuite être __version__.pygénérée par setup.py.

Pas directement une réponse à votre question, mais vous devriez envisager de la nommer __version__, pasversion .

Il s'agit presque d'un quasi-standard. De nombreux modules dans la bibliothèque standard utilisent __version__, et cela est également utilisé en lots modules tiers, c'est donc le quasi-standard.

Habituellement, __version__c'est une chaîne, mais parfois c'est aussi un flottant ou un tuple.

Edit: comme mentionné par S.Lott (Merci!), PEP 8 le dit explicitement:

Noms de donjon au niveau du module

Niveau du module « dunders » ( à savoir les noms avec deux grands et deux underscores de suivi) , tels que __all__, __author__, __version__, etc. doivent être placés après le module docstring mais avant toute déclaration à l'importation , à l' exception de l' __future__importation.

Vous devez également vous assurer que le numéro de version est conforme au format décrit dans PEP 440 ( PEP 386 une version précédente de cette norme).

J'utilise un seul _version.pyfichier comme "lieu une fois canonique" pour stocker les informations de version:

1. Il fournit un __version__attribut.

2. Il fournit la version standard des métadonnées. Par conséquent, il sera détecté par pkg_resourcesou d'autres outils qui analysent les métadonnées du package (EGG-INFO et / ou PKG-INFO, PEP 0345).

3. Il n'importe pas votre package (ou toute autre chose) lors de la construction de votre package, ce qui peut provoquer des problèmes dans certaines situations. (Voir les commentaires ci-dessous sur les problèmes que cela peut causer.)

4. Il n'y a qu'un seul endroit où le numéro de version est écrit, donc il n'y a qu'un seul endroit pour le changer lorsque le numéro de version change, et il y a moins de chance de versions incohérentes.

Voici comment cela fonctionne: le "seul endroit canonique" pour stocker le numéro de version est un fichier .py, nommé "_version.py" qui se trouve dans votre package Python, par exemple dans myniftyapp/_version.py. Ce fichier est un module Python, mais votre setup.py ne l'importe pas! (Cela annulerait la fonctionnalité 3.) Au lieu de cela, votre setup.py sait que le contenu de ce fichier est très simple, quelque chose comme:

__version__ = "3.6.5"

Et donc votre setup.py ouvre le fichier et l'analyse, avec du code comme:

import re
VERSIONFILE="myniftyapp/_version.py"
verstrline = open(VERSIONFILE, "rt").read()
VSRE = r"^__version__ = ['\"]([^'\"]*)['\"]"
mo = re.search(VSRE, verstrline, re.M)
if mo:
    verstr = mo.group(1)
else:
    raise RuntimeError("Unable to find version string in %s." % (VERSIONFILE,))

Ensuite, votre setup.py transmet cette chaîne en tant que valeur de l'argument "version" à setup(), satisfaisant ainsi la fonctionnalité 2.

Pour satisfaire la fonctionnalité 1, vous pouvez demander à votre package (au moment de l'exécution, pas au moment de l'installation!) D'importer le fichier _version myniftyapp/__init__.pycomme ceci:

from _version import __version__

Voici un exemple de cette technique que j'utilise depuis des années.

Le code de cet exemple est un peu plus compliqué, mais l'exemple simplifié que j'ai écrit dans ce commentaire devrait être une implémentation complète.

Voici un exemple de code d'importation de la version .

Si vous voyez quelque chose de mal avec cette approche, faites-le moi savoir.

Réécrit 2017-05

Après plus de dix ans d'écriture de code Python et de gestion de divers packages, je suis arrivé à la conclusion que le bricolage n'est peut-être pas la meilleure approche.

J'ai commencé à utiliser le pbrpackage pour gérer les versions dans mes packages. Si vous utilisez git comme SCM, cela s'intégrera à votre flux de travail comme par magie, économisant ainsi vos semaines de travail (vous serez surpris de la complexité du problème).

À ce jour, pbr est classé n ° 11 des packages python les plus utilisés et atteindre ce niveau n'incluait aucun truc sale: n'en était qu'un: résoudre un problème de packaging commun de manière très simple.

pbr peut faire plus de la charge de maintenance des packages, ne se limite pas au versioning mais ne vous oblige pas à adopter tous ses avantages.

Donc, pour vous donner une idée de la façon dont il semble adopter pbr en un seul commit, jetez un œil à l' emballage pbr

Vous auriez probablement remarqué que la version n'est pas du tout stockée dans le référentiel. PBR le détecte à partir des branches et des balises Git.

Pas besoin de vous soucier de ce qui se passe lorsque vous n'avez pas de référentiel git car pbr "compile" et met en cache la version lorsque vous empaquetez ou installez les applications, il n'y a donc pas de dépendance d'exécution sur git.

Ancienne solution

Voici la meilleure solution que j'ai vue jusqu'à présent et elle explique également pourquoi:

À l'intérieur yourpackage/version.py:

# Store the version here so:
# 1) we don't load dependencies by storing it in __init__.py
# 2) we can import it in setup.py for the same reason
# 3) we can import it into your module module
__version__ = '0.12'

À l'intérieur yourpackage/__init__.py:

from .version import __version__

À l'intérieur setup.py:

exec(open('yourpackage/version.py').read())
setup(
    ...
    version=__version__,
    ...

Si vous connaissez une autre approche qui semble meilleure, faites-le moi savoir.

Selon le PEP 396 différé (numéros de version de module) , il existe une méthode proposée pour le faire. Il décrit, avec justification, une norme (certes facultative) pour les modules à suivre. Voici un extrait:

3) Lorsqu'un module (ou package) inclut un numéro de version, la version DEVRAIT être disponible dans l' __version__attribut.

4) Pour les modules qui vivent à l'intérieur d'un paquet d'espace de noms, le module DEVRAIT inclure l' __version__attribut. Le package d'espace de noms lui-même NE DEVRAIT PAS inclure son propre __version__attribut.

5) La __version__valeur de l'attribut DEVRAIT être une chaîne.

Bien que ce soit probablement beaucoup trop tard, il existe une alternative légèrement plus simple à la réponse précédente:

__version_info__ = ('1', '2', '3')
__version__ = '.'.join(__version_info__)

(Et il serait assez simple de convertir des portions de numéros de version à incrémentation automatique en une chaîne à l'aide str() .)

Bien sûr, d'après ce que j'ai vu, les gens ont tendance à utiliser quelque chose comme la version mentionnée précédemment lors de l'utilisation __version_info__, et en tant que telle, à la stocker comme un tuple d'ints; cependant, je ne vois pas vraiment l'intérêt de le faire, car je doute qu'il y ait des situations où vous effectueriez des opérations mathématiques telles que l'addition et la soustraction sur des parties de numéros de version à des fins autres que la curiosité ou l'incrémentation automatique (et même alors, int()et str()peut être utilisé assez facilement). (D'un autre côté, il est possible que le code de quelqu'un d'autre s'attende à un tuple numérique plutôt qu'à un tuple de chaîne et échoue donc.)

Ceci est, bien sûr, mon propre point de vue, et j'aimerais volontiers que les autres me disent comment utiliser un tuple numérique.

Comme Shezi me l'a rappelé, les comparaisons (lexicales) de chaînes de nombres n'ont pas nécessairement le même résultat que les comparaisons numériques directes; les zéros en tête seraient tenus de le prévoir. Ainsi, au final, le stockage __version_info__(ou son nom) sous la forme d'un tuple de valeurs entières permettrait des comparaisons de versions plus efficaces.

Beaucoup de ces solutions ignorent les gitbalises de version, ce qui signifie que vous devez suivre la version à plusieurs endroits (mauvais). Je l'ai abordé avec les objectifs suivants:

• Dérivez toutes les références de version python à partir d'une balise dans le git référentiel
• Automatisez git tag/ pushet les setup.py uploadétapes avec une seule commande qui ne prend aucune entrée.

Comment ça fonctionne:

1. À partir d'une make releasecommande, la dernière version balisée du dépôt git est trouvée et incrémentée. La balise est repoussée à origin.

2. Le Makefilestocke la version dans src/_version.pylaquelle elle sera lue setup.pyet également incluse dans la version. Ne vérifiez pas le contrôle de _version.pysource!

3. setup.pycommande lit la nouvelle chaîne de version package.__version__.

Détails:

Makefile

# remove optional 'v' and trailing hash "v1.0-N-HASH" -> "v1.0-N"
git_describe_ver = $(shell git describe --tags | sed -E -e 's/^v//' -e 's/(.*)-.*/\1/')
git_tag_ver      = $(shell git describe --abbrev=0)
next_patch_ver = $(shell python versionbump.py --patch $(call git_tag_ver))
next_minor_ver = $(shell python versionbump.py --minor $(call git_tag_ver))
next_major_ver = $(shell python versionbump.py --major $(call git_tag_ver))

.PHONY: ${MODULE}/_version.py
${MODULE}/_version.py:
    echo '__version__ = "$(call git_describe_ver)"' > $@

.PHONY: release
release: test lint mypy
    git tag -a $(call next_patch_ver)
    $(MAKE) ${MODULE}/_version.py
    python setup.py check sdist upload # (legacy "upload" method)
    # twine upload dist/*  (preferred method)
    git push origin master --tags

La releasecible incrémente toujours le 3e chiffre de la version, mais vous pouvez utiliser le next_minor_verou next_major_verpour incrémenter les autres chiffres. Les commandes reposent surversionbump.py script qui est archivé à la racine du dépôt

versionbump.py

"""An auto-increment tool for version strings."""

import sys
import unittest

import click
from click.testing import CliRunner  # type: ignore

__version__ = '0.1'

MIN_DIGITS = 2
MAX_DIGITS = 3


@click.command()
@click.argument('version')
@click.option('--major', 'bump_idx', flag_value=0, help='Increment major number.')
@click.option('--minor', 'bump_idx', flag_value=1, help='Increment minor number.')
@click.option('--patch', 'bump_idx', flag_value=2, default=True, help='Increment patch number.')
def cli(version: str, bump_idx: int) -> None:
    """Bumps a MAJOR.MINOR.PATCH version string at the specified index location or 'patch' digit. An
    optional 'v' prefix is allowed and will be included in the output if found."""
    prefix = version[0] if version[0].isalpha() else ''
    digits = version.lower().lstrip('v').split('.')

    if len(digits) > MAX_DIGITS:
        click.secho('ERROR: Too many digits', fg='red', err=True)
        sys.exit(1)

    digits = (digits + ['0'] * MAX_DIGITS)[:MAX_DIGITS]  # Extend total digits to max.
    digits[bump_idx] = str(int(digits[bump_idx]) + 1)  # Increment the desired digit.

    # Zero rightmost digits after bump position.
    for i in range(bump_idx + 1, MAX_DIGITS):
        digits[i] = '0'
    digits = digits[:max(MIN_DIGITS, bump_idx + 1)]  # Trim rightmost digits.
    click.echo(prefix + '.'.join(digits), nl=False)


if __name__ == '__main__':
    cli()  # pylint: disable=no-value-for-parameter

Cela fait le gros du travail comment traiter et incrémenter le numéro de version de git .

__init__.py

Le my_module/_version.pyfichier est importé dans my_module/__init__.py. Mettez ici toute configuration d'installation statique que vous souhaitez distribuer avec votre module.

from ._version import __version__
__author__ = ''
__email__ = ''

setup.py

La dernière étape consiste à lire les informations de version du my_modulemodule.

from setuptools import setup, find_packages

pkg_vars  = {}

with open("{MODULE}/_version.py") as fp:
    exec(fp.read(), pkg_vars)

setup(
    version=pkg_vars['__version__'],
    ...
    ...
)

Bien sûr, pour que tout cela fonctionne, vous devrez avoir au moins une balise de version dans votre référentiel pour commencer.

git tag -a v0.0.1

J'utilise un fichier JSON dans le répertoire du package. Cela correspond aux exigences de Zooko.

À l'intérieur pkg_dir/pkg_info.json:

{"version": "0.1.0"}

À l'intérieur setup.py:

from distutils.core import setup
import json

with open('pkg_dir/pkg_info.json') as fp:
    _info = json.load(fp)

setup(
    version=_info['version'],
    ...
    )

À l'intérieur pkg_dir/__init__.py:

import json
from os.path import dirname

with open(dirname(__file__) + '/pkg_info.json') as fp:
    _info = json.load(fp)

__version__ = _info['version']

J'ai également mis d'autres informations pkg_info.json, comme l'auteur. J'aime utiliser JSON car je peux automatiser la gestion des métadonnées.

Il convient également de noter que, en plus d' __version__être semi-standard. en python est donc __version_info__ce qui est un tuple, dans les cas simples, vous pouvez simplement faire quelque chose comme:

__version__ = '1.2.3'
__version_info__ = tuple([ int(num) for num in __version__.split('.')])

... et vous pouvez obtenir la __version__chaîne à partir d'un fichier, ou autre chose.

Il ne semble pas exister de méthode standard pour incorporer une chaîne de version dans un package python. La plupart des packages que j'ai vus utilisent une variante de votre solution, c'est-à-dire eitner

1. Incorporez la version setup.pyet setup.pygénérez un module (par exemple version.py) contenant uniquement les informations de version, qui sont importées par votre package, ou

2. L'inverse: mettez les informations de version dans votre package lui-même, et importez -les pour définir la version dans setup.py

la flèche le gère d'une manière intéressante.

Maintenant (depuis 2e5031b )

Dans arrow/__init__.py:

__version__ = 'x.y.z'

Dans setup.py:

from arrow import __version__

setup(
    name='arrow',
    version=__version__,
    # [...]
)

Avant

Dans arrow/__init__.py:

__version__ = 'x.y.z'
VERSION = __version__

Dans setup.py:

def grep(attrname):
    pattern = r"{0}\W*=\W*'([^']+)'".format(attrname)
    strval, = re.findall(pattern, file_text)
    return strval

file_text = read(fpath('arrow/__init__.py'))

setup(
    name='arrow',
    version=grep('__version__'),
    # [...]
)

J'ai aussi vu un autre style:

>>> django.VERSION
(1, 1, 0, 'final', 0)

En utilisant setuptools etpbr

Il n'y a pas de façon standard de gérer la version, mais la façon standard de gérer vos packages est setuptools .

La meilleure solution que j'ai trouvée dans l'ensemble pour gérer la version est d'utiliser setuptools avec l' pbrextension. C'est maintenant ma façon standard de gérer la version.

La configuration de votre projet pour un emballage complet peut être exagérée pour des projets simples, mais si vous avez besoin de gérer la version, vous êtes probablement au bon niveau pour tout configurer. Cela rend également votre package libérable sur PyPi afin que tout le monde puisse le télécharger et l'utiliser avec Pip.

PBR déplace la plupart des métadonnées hors des setup.pyoutils et dans un setup.cfgfichier qui est ensuite utilisé comme source pour la plupart des métadonnées, qui peuvent inclure la version. Cela permet aux métadonnées d'être empaquetées dans un exécutable en utilisant quelque chose comme pyinstallersi nécessaire (si c'est le cas, vous aurez probablement besoin de ces informations ), et sépare les métadonnées des autres scripts de gestion / configuration de package. Vous pouvez directement mettre à jour la chaîne de version danssetup.cfg manuellement, et elle sera tirée dans le*.egg-info dossier lors de la création des versions de votre package. Vos scripts peuvent ensuite accéder à la version à partir des métadonnées en utilisant différentes méthodes (ces processus sont décrits dans les sections ci-dessous).

Lorsque vous utilisez Git pour VCS / SCM, cette configuration est encore meilleure, car elle extrait de nombreuses métadonnées de Git afin que votre référentiel puisse être votre principale source de vérité pour certaines des métadonnées, y compris la version, les auteurs, les journaux des modifications, etc. Pour la version en particulier, il créera une chaîne de version pour la validation actuelle basée sur les balises git dans le référentiel.

• PyPA - Empaqueter des packages Python avec SetupTools - Tutoriel
• Documentation d'utilisation de la dernière version de PBR - Comment configurer un 8 lignes setup.pyet un setup.cfgfichier avec les métadonnées.

Comme PBR extraira la version, l'auteur, le journal des modifications et d'autres informations directement à partir de votre dépôt git, certaines des métadonnées setup.cfgpeuvent être omises et générées automatiquement chaque fois qu'une distribution est créée pour votre package (en utilisant setup.py)

Version actuelle en temps réel

setuptoolstirera les dernières informations en temps réel en utilisant setup.py:

python setup.py --version

Cela extraira la dernière version du setup.cfgfichier ou du dépôt git, en fonction de la dernière validation effectuée et des balises qui existent dans le dépôt. Cette commande ne met cependant pas à jour la version dans une distribution.

Mise à jour de la version

Lorsque vous créez une distribution avec setup.py(c'est-à py setup.py sdist- dire , par exemple), toutes les informations actuelles seront extraites et stockées dans la distribution. Cela exécute essentiellement la setup.py --versioncommande, puis stocke ces informations de version dans le package.egg-infodossier dans un ensemble de fichiers qui stockent les métadonnées de distribution.

Remarque sur le processus de mise à jour des métadonnées de version:

Si vous n'utilisez pas pbr pour extraire les données de version de git, mettez simplement à jour votre setup.cfg directement avec les nouvelles informations de version (assez facile, mais assurez-vous qu'il s'agit d'une partie standard de votre processus de publication).

Si vous utilisez git et que vous n'avez pas besoin de créer une distribution source ou binaire (en utilisant l' python setup.py sdistune des python setup.py bdist_xxxcommandes), la façon la plus simple de mettre à jour les informations de dépôt git dans votre <mypackage>.egg-infodossier de métadonnées consiste simplement à exécuter la python setup.py installcommande. Cela exécutera toutes les fonctions PBR liées à l'extraction des métadonnées du référentiel git et mettra à jour votre .egg-infodossier local , installera les exécutables de script pour tous les points d'entrée que vous avez définis et d'autres fonctions que vous pouvez voir à partir de la sortie lorsque vous exécutez cette commande.

Notez que le .egg-infodossier est généralement exclu du stockage dans le référentiel git lui-même dans des .gitignorefichiers Python standard (tels que Gitignore.IO ), car il peut être généré à partir de votre source. S'il est exclu, assurez-vous que vous disposez d'un «processus de publication» standard pour obtenir les métadonnées mises à jour localement avant la publication, et tout package que vous téléchargez sur PyPi.org ou distribuez d'une autre manière doit inclure ces données pour avoir la version correcte. Si vous souhaitez que le référentiel Git contienne ces informations, vous pouvez exclure certains fichiers spécifiques d'être ignorés (c'est- !*.egg-info/PKG_INFOà- dire les ajouter à .gitignore)

Accéder à la version à partir d'un script

Vous pouvez accéder aux métadonnées à partir de la version actuelle dans les scripts Python du package lui-même. Pour la version, par exemple, il y a plusieurs façons de le faire jusqu'à présent:

## This one is a new built-in as of Python 3.8.0 should become the standard
from importlib-metadata import version

v0 = version("mypackage")
print('v0 {}'.format(v0))

## I don't like this one because the version method is hidden
import pkg_resources  # part of setuptools

v1 = pkg_resources.require("mypackage")[0].version
print('v1 {}'.format(v1))

# Probably best for pre v3.8.0 - the output without .version is just a longer string with
# both the package name, a space, and the version string
import pkg_resources  # part of setuptools

v2 = pkg_resources.get_distribution('mypackage').version
print('v2 {}'.format(v2))

## This one seems to be slower, and with pyinstaller makes the exe a lot bigger
from pbr.version import VersionInfo

v3 = VersionInfo('mypackage').release_string()
print('v3 {}'.format(v3))

Vous pouvez en mettre un directement dans votre __init__.pypackage pour extraire les informations de version comme suit, de la même manière que pour certaines autres réponses:

__all__ = (
    '__version__',
    'my_package_name'
)

import pkg_resources  # part of setuptools

__version__ = pkg_resources.get_distribution("mypackage").version

Après plusieurs heures à essayer de trouver la solution fiable la plus simple, voici les pièces:

créez un fichier version.py DANS le dossier de votre package "/ mypackage":

# Store the version here so:
# 1) we don't load dependencies by storing it in __init__.py
# 2) we can import it in setup.py for the same reason
# 3) we can import it into your module module
__version__ = '1.2.7'

dans setup.py:

exec(open('mypackage/version.py').read())
setup(
    name='mypackage',
    version=__version__,

dans le dossier principal init .py:

from .version import __version__

La exec()fonction exécute le script en dehors de toute importation, car setup.py est exécuté avant que le module puisse être importé. Il vous suffit de gérer le numéro de version dans un fichier en un seul endroit, mais malheureusement ce n'est pas dans setup.py. (c'est l'inconvénient, mais l'absence de bogues d'importation est l'avantage)

Beaucoup de travail vers un versionnage uniforme et à l'appui des conventions a été accompli depuis la première question posée . Les options de goût sont maintenant détaillées dans le Guide de l'utilisateur de l'emballage Python . Il convient également de noter que les schémas de numéros de version sont relativement stricts en Python selon PEP 440 , et donc garder les choses saines est essentiel si votre package sera publié dans la boutique de fromage .

Voici une ventilation raccourcie des options de version:

1. Lisez le fichier dans setup.py( setuptools ) et obtenez la version.
2. Utilisez un outil de construction externe (pour mettre à jour les deux __init__.pyainsi que le contrôle des sources), par exemple bump2version , changes ou zest.releaser .
3. Définissez la valeur sur __version__ variable globale dans un module spécifique.
4. Placez la valeur dans un fichier texte VERSION simple pour setup.py et le code à lire.
5. Définissez la valeur via une setup.pyversion et utilisez importlib.metadata pour la récupérer lors de l'exécution. (Attention, il existe des versions pré-3.8 et post-3.8.)
6. Définissez la valeur sur __version__in sample/__init__.pyet importez l'échantillon dans setup.py.
7. Utilisez setuptools_scm pour extraire le contrôle de version du contrôle de source afin qu'il soit la référence canonique, pas le code.

NOTEZ que (7) pourrait être l' approche la plus moderne (les métadonnées de construction sont indépendantes du code, publiées par l'automatisation). En outre NOTE que si l' installation est utilisée pour la libération du package simple python3 setup.py --versionrapportera directement la version.

Pour ce que ça vaut, si vous utilisez des distutils NumPy, numpy.distutils.misc_util.Configurationa une make_svn_version_py()méthode qui incorpore le numéro de révision à l'intérieur package.__svn_version__de la variable version.

1. Utilisez un version.pyfichier uniquement avec __version__ = <VERSION>param dans le fichier. Dans le setup.pyfichier, importez le __version__paramètre et mettez sa valeur dans le setup.pyfichier comme ceci: version=__version__
2. Une autre façon consiste à utiliser uniquement un setup.pyfichier avec version=<CURRENT_VERSION>- la CURRENT_VERSION est codée en dur.

Puisque nous ne voulons pas changer manuellement la version dans le fichier chaque fois que nous créons une nouvelle balise (prête à publier une nouvelle version de package), nous pouvons utiliser ce qui suit.

Je recommande fortement le package bumpversion . Je l'utilise depuis des années pour bump une version.

commencez par ajouter version=<VERSION>à votre setup.pyfichier si vous ne l'avez pas déjà.

Vous devriez utiliser un court script comme celui-ci chaque fois que vous augmentez une version:

bumpversion (patch|minor|major) - choose only one option
git push
git push --tags

Ajoutez ensuite un fichier par dépôt appelé .bumpversion.cfg::

[bumpversion]
current_version = <CURRENT_TAG>
commit = True
tag = True
tag_name = {new_version}
[bumpversion:file:<RELATIVE_PATH_TO_SETUP_FILE>]

Remarque:

• Vous pouvez utiliser __version__ paramètre sous le version.pyfichier comme cela a été suggéré dans d'autres articles et mettre à jour le fichier bumpversion comme ceci: [bumpversion:file:<RELATIVE_PATH_TO_VERSION_FILE>]
• Vous devez git commit ougit reset tout dans votre repo, sinon vous obtiendrez une erreur de repo sale.
• Assurez-vous que votre environnement virtuel inclut le package de bumpversion, sans quoi il ne fonctionnera pas.

Si vous utilisez CVS (ou RCS) et souhaitez une solution rapide, vous pouvez utiliser:

__version__ = "$Revision: 1.1 $"[11:-2]
__version_info__ = tuple([int(s) for s in __version__.split(".")])

(Bien sûr, le numéro de révision vous sera remplacé par CVS.)

Cela vous donne une version imprimable et des informations de version que vous pouvez utiliser pour vérifier que le module que vous importez a au moins la version attendue:

import my_module
assert my_module.__version_info__ >= (1, 1)