De manière Standard pour intégrer la version en python package?

Est-il un moyen standard pour associer chaîne de version avec un paquet python dans une telle manière que je pourrais faire la suite?

import foo
print foo.version

J'imagine, il y a une certaine façon de récupérer des données sans aucun supplément de coder en dur, depuis le mineur/majeur cordes sont spécifiés dans setup.py déjà. Autre solution que j'ai trouvé était d'avoir import __version__ dans mon foo/__init__.py puis ont __version__.py généré par setup.py.

Pour info, il y a une très bonne vue d'ensemble sur: packaging.python.org/en/latest/...
La Version d'un paquet peut être récupéré à partir de métadonnées avec setuptools, de sorte que dans de nombreux cas, de mettre uniquement sur la version en setup.py est assez. Voir cette question.
Pour info, il existe 5 modèles communs afin de maintenir la source unique de la vérité (au niveau de la configuration et de temps d'exécution) pour le numéro de version.
Python la documentation de listes 7 options différentes pour un seul acidification. N'est-ce pas en contradiction avec la notion de "source unique de vérité"?
pas sûr de ce que vous demandez. Il existe de nombreuses façons qui y sont énumérés, parce que l'emballage guide ne veut pas être opiniâtre.

InformationsquelleAutor Dimitri Tcaciuc | 2009-01-19

119

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

C'est presque un quasi-standard. De nombreux modules de la bibliothèque standard, utilisation __version__, et c'est aussi utilisé dans beaucoup de la 3e partie des modules, c'est donc la quasi-standard.

Généralement, __version__ est une chaîne, mais parfois, c'est aussi un float ou un tuple.

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

Au Niveau Du Module Dsous Noms

Au niveau du Module "dunders" (i.e. les noms avec les deux grands et deux de fuite
des traits de soulignement) comme __all__, __author__, __version__, etc.
doit être placé après le module de docstring mais avant toute importation
les déclarations à l'exception de __future__ importations.

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 la présente norme).
- Il devrait être une chaîne de caractères, et un version_info pour le tuple version.
- James: Pourquoi __version_info__ en particulier? (Qui "invente" votre propre double-trait de soulignement de mots.) [Quand James a commenté, des traits de soulignement n'a rien fait dans les commentaires, maintenant, ils indiquent l'accent, de sorte que James a vraiment écrit __version_info__ trop. ---ed.]
- Vous pouvez voir quelque chose à propos de ce version doit dire à packages.python.org/distribute/... Cette page est à propos de les distribuer, mais la signification du numéro de version est en train de devenir un standard de facto.
- En dépit de ce que la PEP 8 dit, il est hautement souhaitable que le contenu de __version__ à suivre les règles de PEP 386, qui permettent à des numéros de version pour être fiable comparé.
- Ce qui nous ramène à la question suivante: si version est destiné à être comparables et PEP-386/440 conforme, qui s'oppose à l'utilisation mentionnées dans la PEP-8 de contenant VCS mot-clé-caractères d'expansion. D'où vient donc de mon git de hachage ou RCS $Revision$ aller? Dans version? Si oui, où est-ce que mon PEP-440 "0:0.0.0.0.0.0rc0.post0.dev0-0.0.0.0" version locale aller?
- La droite. Semble que ces PEPs se contredisent l'une l'autre. Eh bien, PEP 8 dit "si" et "crud", de sorte qu'il n'a pas vraiment d'approuver à l'aide de VCS l'expansion de mots clés. Aussi, si jamais vous passez à un autre VCS, vous perdrez les informations relatives à la révision. Par conséquent, je suggère à l'aide d'un PEP 386/440 version compatible avec les informations incorporées dans un fichier source unique, au moins pour les grands projets.
- Génial. Et puis aller plus loin et faire une option de ligne de commande (-v, --version) pour l'impression de la version. L'utilisation de 'optparse': docs.python.org/3/library/optparse.html#module-optparse
- Où placeriez-vous que version. Considérant que c'est accepté, je serais ravi de voir que des infos supplémentaires ici.
- PEP 8 ne prend pas en dire plus.
- merci pour l'astuce! PEP8 mentionne encore ‘version’, mais heureusement, ils se sont débarrassés de cette VCS crud. Mis à jour en conséquence
InformationsquelleAutor oefe
108

- Je utiliser un seul _version.py fichier en tant que "une fois que cannonical place" pour stocker les informations de version:
1. Il fournit un __version__ attribut.
2. Il fournit la norme de métadonnées version. Par conséquent, il sera détecté par pkg_resources ou d'autres outils qui analysent le paquet de métadonnées (EGG-INFO et/ou PKG-INFO, PEP 0345).
3. Il n'a pas d'importation de votre colis (ou autre chose) lors de la construction de votre colis, ce qui peut causer des problèmes dans certaines situations. (Voir les commentaires ci-dessous sur ce que les problèmes que cela peut causer.)
4. Il n'y a qu'un seul endroit que le numéro de version est écrite, donc il n'y a qu'un seul endroit à en changer lorsque le numéro de version change, et il ya moins de chance de versions incompatibles.
Voici comment ça fonctionne: le "canonique" pour enregistrer le numéro de version est un .py fichier, nommé "_version.py" ce qui est dans votre paquet Python, par exemple dans myniftyapp/_version.py. Ce fichier est un module Python, mais votre setup.py ne pas l'importer! (Qui irait à l'encontre de fonction 3.) Au lieu de 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 un 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,))
```
Alors votre setup.py passe d'une chaîne de caractères comme la valeur de la "version" argument de setup(), satisfaisant ainsi de caractéristique 2.

Pour satisfaire caractéristique 1, vous pouvez avoir votre colis (au moment de l'exécution, et non pas au moment de l'installation!) importer le _version fichier de myniftyapp/__init__.py comme ceci:
```
from _version import __version__
```
Ici est un exemple de cette technique que j'ai utilisé pendant des années.

Le code de cet exemple est un peu plus compliqué, mais l'exemple simplifié que j'ai écrit dans ce commentaire doit être une mise en œuvre complète.

Ici est exemple de code de l'importation de la version.

Si vous voyez quelque chose de mal avec cette approche, s'il vous plaît laissez-moi savoir.
- Pourriez-vous décrire les problèmes qui motivent #3? Glyphe a dit qu'il avait quelque chose à voir avec "setuptools aime à prétendre que votre code n'est pas n'importe où sur le système lors de vos setup.py fonctionne", mais les détails de cette aide à convaincre moi et les autres.
- si votre setup.py est en cours d'exécution dans un fraîchement créé Python processus et de votre répertoire de travail courant est le répertoire qui contient votre projet, puis il va travailler. C'est la façon la plus commune que les programmeurs exécuter setup.py, ils pensent donc que c'est le seul moyen. Mais il existe d'autres moyens! Des outils comme py2exe exécuter une seule Python processus, puis de charger et d'exécuter le setup.py des scripts à partir d'un projet après l'autre (alors que l'emballage de tous ensemble). Supposons que certains de code Python qui a couru avant votre setup.py script importé d'une autre version de votre module.
- Je pense qu'il y a peut être d'autres problèmes avec l'importation de votre colis, trop. Considérer qu'un outil comme setuptools ou pip doit faire deux choses pour les packages de déclarer les dépendances: 1. construire ce package, 2. installer (premier bâtiment, si nécessaire) de ses dépendances.
- Maintenant, quel ordre doit-on le outil de le faire dans? Il ne peut pas (dans le setuptools/pip/virtualenv système d'aujourd'hui) même savoir ce que le deps est jusqu'à ce qu'il évalue votre setup.py. Aussi, si il a essayé de faire plein de profondeur d'abord et de faire tous les deps avant qu'il ne, il serait coincé si il y avait circulaire de deps. Mais si elle tente de construire ce paquet avant d'installer les dépendances, alors si vous importez votre colis auprès de votre setup.py, il ne sera pas nécessairement capable d'importer son deps, ou le droit à des versions de ses deps.
- Ci-dessus, j'ai écrit: "si votre setup.py est en cours d'exécution dans un fraîchement créé Python processus et de votre répertoire de travail courant est le répertoire qui contient votre projet, ensuite, il sera" je l'aurais écrit: "si votre setup.py est en cours d'exécution dans un fraîchement créé Python processus et de votre répertoire de travail courant est le répertoire qui contient votre projet, et toutes ses dépendances dont il a besoin lorsqu'il est importé sont déjà installés, il fonctionnera"
- Pourriez-vous écrire fichier "version.py" à partir de "setup.py" au lieu de l'analyser? Qui semble plus simple.
- Grande réponse. De légères rides pour les lecteurs à connaître: le type de Version (alpha, bêta, candidats, finale, post, etc...) est dupliquée dans la version comme indiqué ci-dessus, et le trésor des classificateurs, si vous les indiquer.
- Jonathan Hartley: je suis d'accord qu'il serait un peu plus simple pour votre "setup.py" pour écrire les "version.py" fichier au lieu de l'analyser, mais il permettrait d'ouvrir une fenêtre pour l'incohérence, lorsque vous avez édité votre setup.py pour avoir la nouvelle version mais je n'ai pas encore exécuté setup.py pour mettre à jour le version.py fichier. Une autre raison à la version canonique être dans un petit fichier séparé, c'est qu'il le rend facile pour autres outils, tels que des outils qui lisent votre contrôle de révision de l'état, à l'écriture de la version du fichier.
- Approche similaire est à execfile("myniftyapp/_version.py") de l'intérieur setup.py plutôt que d'essayer d'analyser le code de version manuellement. Suggéré dans stackoverflow.com/a/2073599/647002 -- discussion, il peut être utile, aussi.
- Voici une surtout-outil complémentaire par ma longue-programmation du temps de partenaire Brian Warner: blog.mozilla.org/warner/2012/01/31/... Versioneer est un outil pour générer le numéro de version du git de l'histoire. Idéalement, je voudrais utiliser Versioneer pour générer le numéro de version, puis utiliser la technique décrite dans ma réponse ici pour faire que le numéro de version disponibles à tous les endroits où elle est nécessaire. Je suis en train de faire quelque chose comme ça dans ce projet: github.com/zooko/pycryptopp
- +1. Aucune raison de ne pas avoir un fichier __version__ qui ne contient que la version (1.2.3) et ensuite de lire que dans setup.py ainsi que dans votre forfait? (Pas d'analyse est nécessaire dans cette voie...)
- - Je ajouter __version_info__ = tuple(map(int, __version__.split('.'))) pour que.
- Devrait être from ._version import __version__ à tirer dans le _version module de _version.py dans le projet local et pas une autre flottant autour dans votre environnement.
- Votre premier lien est rompu.
InformationsquelleAutor Zooko
96

Réécrit 2017-05

Après plus de dix ans d'écriture de code Python et la gestion des différents paquets, je suis venu à la conclusion que le BRICOLAGE, c'est peut-être pas la meilleure approche.

J'ai commencé à utiliser pbr paquet pour traiter avec gestion des versions dans mes paquets. Si vous utilisez git comme SCM, il s'adapte à votre flux de travail, comme par magie, la sauvegarde de vos semaines de travail (vous serez surpris par la complexité de la question peut être).

À compter d'aujourd'hui pbr est classé #11 le plus utilisé paquet python et l'atteinte de ce niveau ne comprend pas tout de sales tours: a une seule: la fixation d'une commune de l'emballage problème d'une manière très simple.

pbr en peut plus de l'emballage le fardeau de l'entretien, n'est pas limitée à la production de versions, mais il ne fait pas de vous forcer à adopter l'ensemble de ses prestations.

Donc, pour vous donner une idée de à quoi il ressemble à adopter des droits d'obtenteur dans un commit ont un look swiching emballage pour pbr

Probablement vous observé que la version n'est pas stocké dans le repository. Droits d'OBTENTEUR ne le détecte à partir de Git branches et de tags.

Pas besoin de s'inquiéter à propos de ce qui se passe lorsque vous ne disposez pas d'un dépôt git à cause des droits d'obtenteur ne "compiler" et le cache de la version lorsque vous créez un package ou d'installer les applications, alors il n'y a pas d'exécution de la dépendance sur git.

Vieille solution

Ici est la meilleure solution que j'ai vu jusqu'à présent et cela explique aussi pourquoi l':

À l'intérieur de 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 de yourpackage/__init__.py:
```
from .version import __version__
```
À l'intérieur de setup.py:
```
exec(open('yourpackage/version.py').read())
setup(
    ...
    version=__version__,
    ...
```
Si vous connaissez une autre approche qui semble être mieux faites le moi savoir.
- Vous devez remplacer exec(open('yourpackage/version.py').read()) avec execfile('yourpackage/version.py').
- Tre, pas de. execfile() n'existe pas en Python 3, il est donc préférable d'utiliser exec(open().read()).
- pourquoi ne pas mettre "version='0.12" directement à setup.py?
- pourquoi ne pas from .version import __version__ dans setup.py ainsi?
- Parce que le paquet n'est pas chargée lors de l' setup.py est en cours d'exécution - essayez, vous allez obtenir une erreur (ou au moins, j'ai fait :-))
- Je suppose que dans Python 2.7+ . est dans sys.path par défaut, donc tant que version module ne pas avoir de dépendances, c'est une façon d'aller.
- Oui, mais le . répertoire est le répertoire avec setup.py, et non pas le répertoire avec le version module...
- Si vous exécutez python setup.py install à partir d'un autre répertoire que le package racine, le rapport de recherche pour version.py échouera
- fonctionne parfaitement, mais il a ajouté chemin absolu pour le rendre plus robuste:here = os.path.abspath(os.path.dirname(__file__)) puis exec(open(os.path.join(here, 'yourpackage/version.py')).read()). Aussi, n'est-ce pas trouver un besoin relatif à l'importation.
- Le lien pour pbr résultats dans un bad gateway.
- Merci de nous aider à passer à pbr (Python Construire caractère Raisonnable)! Il a l'air très prometteur! Il va nous aider à atteindre sur la façon de rendre l'écosystème plus sûr et plus robuste via des fichiers texte comme setup.cfg, plutôt que de BRICOLAGE code qui s'exécute dans setup.py qui a pris la PyPI, pip install et la gestion des exigences des emplois beaucoup plus difficile.
- Pouvez-vous fournir un exemple de la façon de mettre en œuvre pbr pour le contrôle de version?
- droits d'obtenteur, sans aucun doute, est un excellent outil, mais vous avez omis de répondre à la question. Comment pouvez-vous accéder à la version en cours ou le paquet installé à l'aide de rpr.
- pbr est une horrible solution. C'est une application écrite par la communauté openstack pour openstack problèmes, et il introduit une multitude d'opinions et des hypothèses qui peuvent vous vis big up de temps si vous n'êtes pas conscient. Si vous n'avez pas d'écrire du code pour openstack, il y a une forte probabilité qu'il introduit plus de problèmes qu'elle n'en résout.
- Vous n'avez pas besoin des droits d'obtenteur pour accéder à version de l'information, juste obtenir à partir module.__version__ -- en fait, ce droit d'obtenteur n'est automatise la création de ce au moment de la construction et de son entretien lors de l'exécution à partir de git. Si vous utilisez git et balises pour la version ce serait une perte de temps de ne pas bénéficier d'elle. Vrai que le droit d'obtenteur est apparu sur openstack, mais il n'a rien de précis sur ce (sa popularité n'a rien à voir avec openstack). J'espère que l'emballage sur python évoluera donc des droits d'obtenteur ne seraient pas nécessaires.
InformationsquelleAutor sorin
29

Par le report de la PEP 396 (les Numéros de Version), il y a une proposition de méthode pour ce faire. Il décrit, avec justification, un (certes en option) standard pour les modules à suivre. Voici un extrait:

3) Lorsqu'un module (ou package) comprend un numéro de version, la version DEVRAIT être disponible dans le __version__ attribut.

4)
Pour les modules qui vivent à l'intérieur d'un espace de noms de package, le module DOIT inclure la __version__ attribut. L'espace de noms de package lui-même ne DEVRAIT PAS inclure sa propre __version__ attribut.

5)
Le __version__ valeur de l'attribut DOIT être une chaîne.
- Que la PPE n'est pas acceptée ou normalisé, mais en différé (en raison du manque d'intérêt). Donc c'est un peu trompeur d'affirmer que "il y a un moyen standard", a précisé par celui-ci.
- Oh mon! J'ai appris quelque chose de nouveau. Je ne savais pas que c'était quelque chose que je devais vérifier.
- Édité à noter qu'il n'est pas un standard. Maintenant, je me sens gêné, parce que j'ai soulevé demandes de fonctionnalités sur des projets en leur demandant de respecter cette "norme".
- Peut-être vous devrait prendre en charge les travaux de normalisation sur ce PEP, puisque vous semblez intéressé 🙂
- Ce serait le travail pour la gestion des versions d'un module individuel, mais je ne suis pas sûr qu'il pourrait s'appliquer à la gestion des versions d'un projet.
- projet" est un peu vague. Cette question est sur les paquets. Si votre projet est un site web, système embarqué, application de téléphone, application de bureau, ligne de commande, etc., vous aurez besoin d'un autre système, une autre question.
InformationsquelleAutor Oddthinking
21

Si c'est sans doute trop tard, il est un peu plus simple alternative à la réponse précédente:
```
__version_info__ = ('1', '2', '3')
__version__ = '.'.join(__version_info__)
```
(Et il serait assez simple de convertir l'auto-incrémentation des portions de numéros de version d'une chaîne à l'aide de str().)

Bien sûr, de ce que j'ai vu, les gens ont tendance à utiliser quelque chose comme précédemment mentionné version lors de l'utilisation de __version_info__, et en tant que tel magasin comme un n-uplet d'entiers; cependant, je n'arrive pas à voir le point de le faire, car je doute qu'il y a des situations où vous devez effectuer des opérations mathématiques, telles que l'addition et de la soustraction sur des portions de numéros de version pour n'importe quel but, outre la curiosité ou de l'auto-incrémentation (et même alors, int() et str() peut être utilisé assez facilement). (D'un autre côté, il y a la possibilité de quelqu'un d'autre code attend numérique tuple plutôt qu'une chaîne n-uplet et donc défaut.)

C'est, bien sûr, de mon propre point de vue, et je serais heureux de faire comme les autres' entrée sur le numérique à l'aide d'un tuple.

Comme shezi m'a rappelé, (lexicale) les comparaisons de chaînes de nombre n'ont pas forcément le même résultat que le numérique directe des comparaisons; les zéros à gauche serait tenu de fournir pour cela. Donc en fin de compte, le stockage __version_info__ (ou ce qu'il serait appelé) comme un n-uplet de valeurs entières permettrait une plus grande efficacité de la version comparaisons.
- nice (+1), mais ne serait pas vous préférez des chiffres à la place des cordes? par exemple, __version_info__ = (1,2,3)
- Comparaison de chaînes de caractères peuvent devenir dangereux lorsque les numéros de version de dépasser les 9, puisque par exemple, " 10 " < '2'.
- Dans ce cas, vous pouvez simplement utiliser int() pour faire une comparaison de la valeur, ou tout simplement faire ce que orip suggéré et stocker les valeurs comme des nombres entiers.
- Je le fais aussi, mais légèrement modifié à l'adresse ints.. __version_info__ = (0, 1, 0) __version__ = '.'.join(map(str, __version_info__))
- Problème avec __version__ = '.'.join(__version_info__) est que __version_info__ = ('1', '2', 'beta') deviendra 1.2.beta, pas 1.2beta ou 1.2 beta
- Je ne vois pas de problème avec ça. Ce n'est pas ce que la plupart des gens s'attendent à ce, mais il est encore très facilement analysée.
- Je pense que le problème avec cette approche est l'endroit où placer les lignes de code en déclarant l' __version__. Si ils sont dans setup.py ensuite, votre programme ne peut pas les importer à partir de l'intérieur de son emballage. Peut-être que ce n'est pas un problème pour vous, dans ce cas, très bien. Si elles vont à l'intérieur de votre programme, puis votre setup.py peut les importer, mais il ne devrait pas, depuis setup.py est exécuté lors de l'installation dans votre programme, les dépendances ne sont pas encore installés (setup.py est utilisée pour déterminer quelles sont les dépendances sont.) Donc Zooko réponse: manuellement analyser la valeur d'un produit fichier source, sans importer le package de produit
- Si vous définissez <tt>__version__</tr> directement comme une chaîne de caractères ou à l'aide de cette méthode (et l'analyse de <tt>__version_info__</tr> dans setup.py) est orthogonale à l'autre des avantages de Zooko de réponse.
- En utilisant des numéros peuvent aider avec des comparaisons: l'Opéra avait un gros problème quand ils ont été le premier navigateur pour accéder à la version 10. Lire le rapport complet ici: dev.opera.com/articles/view/opera-ua-string-changes
- C'est un problème avec les sous-chaˆ ıne d'analyse plutôt que toute comparaison question, mais vous n'apportez un bon point: les lexicale comparaison d'entiers stockés comme des chaînes de caractères ne sera pas nécessairement la même que la comparaison numérique des deux valeurs. (par exemple, 2 < 10 évalue à True, mais '2' < '10' évalue à False).
- Ce version_info astuce est d'au moins de ne pas en synchronisation avec le correspondant de la PPE. Il a aussi des problèmes de ce @nagisa mentionné.
- Ce n'est pas spécifier où, la version doit être stockée. Quel fichier faut-il situé dans? Cela doit être dans un fichier importé par setup.py?
InformationsquelleAutor JAB
11

Nombre de ces solutions ici ignorer git version balises qui signifie que vous devez suivre les version dans de multiples endroits (bad). Je me suis approché de ce, avec les objectifs suivants:
- Tirer toutes les version de python de références à partir d'une balise dans le git repo
- Automatiser git tag/push et setup.py upload étapes avec une seule commande qui ne prend pas d'entrées.
Comment cela fonctionne:
1. À partir d'un make release de commande, la dernière version après marquage dans le repo git est trouvé et incrémenté. La balise est repoussé à origin.
2. La Makefile magasins de la version en src/_version.py où il sera lu par setup.py et sont également inclus dans le communiqué. Ne pas vérifier _version.py dans le contrôle de source!
3. setup.py commande lit la nouvelle version de la chaîne de 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/(.*)-.*//')
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 release cible incrémente toujours la version 3 chiffres, mais vous pouvez utiliser le next_minor_ver ou next_major_ver pour incrémenter les autres chiffres. Les commandes s'appuyer sur la versionbump.py script qui est vérifié dans la racine de l'opération

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 ne le levage lourd manière de traiter et d'incrémenter le numéro de version de git.

__init__.py

La my_module/_version.py fichier est importé dans my_module/__init__.py. Mettre statique installer config ici que vous voulez distribué avec votre module.
```
from ._version import __version__
__author__ = ''
__email__ = ''
```
setup.py

La dernière étape est de lire les informations de version de l' my_module module.
```
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 devez avoir au moins une balise de version dans votre pension pour commencer.
```
git tag -a v0.0.1
```
- en effet, l'ensemble de ce fil oublie qu'un VCS est très important dans cette discussion. juste une remarque: l'incrémentation de la version doit rester un processus manuel, de sorte que le moyen préféré sera de 1. créer manuellement et pousser un tag 2. laissez VCS outils de découvrir cette marque et de le stocker en cas de besoin (wow - ce DONC, interface de montage est vraiment paralysant moi - j'ai dû modifier une douzaine de fois pour traiter les retours à la ligne ET ÇA NE fonctionne TOUJOURS PAS !@#$%^&*)
- Pas besoin d'utiliser versionbump.py lorsque nous avons un impressionnant bumpversion forfait pour python.
- J'ai regardé versionbump. Les docs ne sont pas très claires, et il ne gère pas de marquage très bien. Dans mon test, il semble entrer dans les états qui en sont la cause de crash: sous-processus.CalledProcessError: Commande '['git', 'commit', '-F', '/var/folders/rl/tjyk4hns7kndnx035p26wg692g_7t8/T/tmppishngbo']' retourné non nulle de sortie d'état 1.
- Un autre tweak est d'utiliser le droit d'OBTENTEUR à gérer certains de la gestion des versions. Vous pouvez utiliser le même processus pour identifier le repo et ensuite de PBR correctement injecter la nouvelle version dans le setup.py de commande.
- Désolé pour la réponse tardive, veuillez vérifier ma réponse: stackoverflow.com/a/48664839/2656748
- Pourquoi ne pas _version.py être suivis avec le contrôle de version?
- Cela complique le processus de diffusion. Maintenant, vous devez vous assurer que vous êtes balises et s'engage correspond à la valeur de _version.py. À l'aide d'une unique balise de version est plus propre de l'OMI, et signifie que vous pouvez créer une version directement à partir de github de l'INTERFACE utilisateur.
InformationsquelleAutor cmcginty
10

- Je utiliser un fichier JSON dans le package dir. Cela correspond Zooko exigences.

À l'intérieur de pkg_dir/pkg_info.json:
```
{"version": "0.1.0"}
```
À l'intérieur de 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 de 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 aussi mis d'autres informations dans pkg_info.json, comme l'auteur. J'
comme pour l'utilisation de JSON parce que je peux automatiser la gestion des métadonnées.
- Pourriez-vous expliquer comment utiliser le json pour l'automatisation de la gestion des métadonnées? Merci!
InformationsquelleAutor Andy Lee
6

Également intéressant de noter, c'est que ainsi que __version__ être un semi-std. en python, donc est __version_info__ qui est un n-uplet, 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 le __version__ chaîne à partir d'un fichier, ou quoi que ce soit.
- Avez-vous des références/liens concernant l'origine de cette utilisation de __version_info__?
- Eh bien c'est la même cartographie que sys.version sys.version_info. Donc: docs.python.org/library/sys.html#sys.version_info
- Il est plus facile de faire de la cartographie dans l'autre sens (__version_info__ = (1, 2, 3) et __version__ = '.'.join(map(str, __version_info__))).
- pour je en __version_info__) - un peu plus long, mais plus pythonic.
- Je ne suis pas sûr que ce que vous proposez est clairement plus pythonic, car il contient une variable muette qui n'est pas vraiment nécessaire, et dont le sens est un peu difficile à exprimer (i n'a pas de sens, version_num est un peu longue et ambigu...). J'ai même pris l'existence de map() en Python comme un indice qu'il devrait être utilisé ici, comme ce que nous devons faire ici, c'est le cas d'utilisation typique de map() (à utiliser avec une fonction existante)—je ne vois pas beaucoup d'autres usages raisonnables.
InformationsquelleAutor James Antill
5

Il ne semble pas être un moyen standard pour intégrer une chaîne de version dans un paquet python. La plupart des paquets que j'ai vu utiliser une variante de votre solution, c'est à dire eitner
1. Intégrer la version en setup.py et ont setup.py générer un module (par exemple version.py) ne contenant que des informations de version, qui ont été importées par votre forfait, ou
2. L'inverse: mettre les informations de version dans votre paquet, et l'importation que de définir la version en setup.py
- J'aime votre recommandation, mais comment générer ce module à partir de setup.py?
- J'aime l'idée de l'option (1), il semble plus simple que Zooko de la réponse de l'analyse du numéro de version à partir d'un fichier. Mais vous ne pouvez pas garantir que version.py est créé quand un dev juste des clones de votre dépôt. À moins que vous vérifiez dans version.py, ce qui ouvre la petite ride de ce que vous pourriez changer le numéro de version dans setup.py, de valider, de libération, puis à slash (oublier) valider la modification de version.py.
- Sans doute que vous pouvez générer le module en utilisant quelque chose comme """avec open("mypackage/version.py", "w") en tant que fp: fp.write("__version__ == '%s'\n" % (__version__,))"""
- Je pense que l'option 2. est sensible à un défaut lors de l'installation comme indiqué dans les commentaires de la commission paritaire de recours de la réponse.
- Ce sujet? Vous mettez __version__ = '0.0.1'" (où la version est une chaîne de caractères, bien sûr) dans l' __init__.py" du paquet principal de votre logiciel. Ensuite pour le point 2: Dans la configuration que vous voulez faire de paquet.__init__ import __version__ en v, puis vous définissez la variable v que la version de votre setup.py. Puis importer mypack que mon, mon impression.__version__ imprime la version. La version sera stockée dans un seul endroit, accessible à partir de l'ensemble du code dans un fichier qui n'importer quoi que ce soit d'autre concernant le logiciel.
InformationsquelleAutor dF.
4

J'ai aussi vu un autre style:
```
>>> django.VERSION
(1, 1, 0, 'final', 0)
```
- Oui, j'ai vu trop. BTW chaque réponse prend un autre style, donc maintenant je ne sais pas ce style est un "standard". La recherche d'mentionné PEPs...
- Une autre façon de voir; Mongo du client Python utilise la version unie, sans les traits de soulignement. Si cela fonctionne; $ python >>> import pymongo >>> pymongo.version 2.7'
- La mise en œuvre de .VERSION ne signifie pas que vous n'avez pas à mettre en œuvre __version__.
- Est-ce à exiger la mise en œuvre de django dans le projet?
InformationsquelleAutor L1ker
3

flèche gère d'une façon 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__'),
# [...]
)
```
- qu'est-ce que file_text?
- la mise à jour de la solution est en fait dangereux. Lorsque setup.py est en cours d'exécution, il ne sera pas forcément voir la version du package à partir du chemin de fichier local. Il pourrait revenir à une version précédemment installée, par exemple, à partir de l'exécution pip install -e . sur une branche de développement ou de quelque chose lors de l'essai. setup.py absolument ne devrait pas compter sur l'importation du package, il est dans le processus de l'installation afin de déterminer les paramètres pour le déploiement. Aïe.
- Oui je ne sais pas pourquoi flèche a décidé de revenir à cette solution. En outre, le message de commit dit "mise à Jour setup.py avec moderne Python normes"...
InformationsquelleAutor Anto
-1

Pour ce que ça vaut, si vous utilisez NumPy distutils, numpy.distutils.misc_util.Configuration a un make_svn_version_py() méthode qui incorpore le numéro de révision à l'intérieur de package.__svn_version__ dans la variable version .
- Pouvez-vous fournir plus de détails ou un exemple de comment cela pourrait fonctionner?
InformationsquelleAutor Matt
-1

À l'aide de setuptools et pbr

La meilleure solution que j'ai trouvé pour l'ensemble de la gestion de version est à utiliser setuptools avec le pbr extension. PBR se déplace la plupart des métadonnées de la setup.py outils et dans un setup.cfg fichier qui est ensuite utilisé comme source pour la plupart des métadonnées, ce qui peut inclure la version.

Lors de l'utilisation de Git pour VCS/SCM, cette configuration est encore mieux, car il va tirer dans un grand nombre de métadonnées à partir de Git, de sorte que votre pension peut être votre principale source de vérité pour certains des métadonnées, y compris la version, les auteurs, les changelogs, etc.
- PyPA - Emballage de Paquets Python avec SetupTools - Tutoriel
- Des droits d'OBTENTEUR dans la dernière version de l'utilisation de la documentation - Comment configurer un 8 ligne setup.py et un setup.cfg fichier de métadonnées.
Comme droit d'OBTENTEUR tirez version, l'auteur, le changelog et d'autres informations directement à partir de votre repo git, de sorte que certaines des métadonnées dans setup.cfg peuvent être laissés de côté et auto généré à chaque fois qu'une distribution de la création de votre colis (à l'aide de setup.py)

En temps réel version actuelle

setuptools va tirer la dernière info en temps réel à l'aide de setup.py:
```
python setup.py --version
```
Cela permettra de tirer la dernière version de la setup.cfg fichier, ou de le repo git, basé sur le dernier commit qui a été faite et les balises qui existent dans le repo. Cette commande ne permet pas de mettre à jour la version dans un réseau de distribution bien.

La mise à jour de la version

Lorsque vous créez une distribution avec setup.py (c'est à dire py setup.py sdist, par exemple), toutes les infos seront extraites et stockées dans la distribution. Essentiellement, cela exécute la setup.py --version de commande, puis stocke que les informations de version dans le package.egg-info dossier dans un ensemble de fichiers de distribution du magasin de métadonnées.

Vous pouvez accéder aux métadonnées de la génération en cours dans les scripts Python dans le paquet lui-même. Pour la version, par exemple, il y a plusieurs façons de faire ce que j'ai trouvé 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))
## This is my favorite - 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 mettre une de ces directement dans votre __init__.py pour le package d'extraire les informations de version comme suit, à l'instar de certaines autres réponses:
```
__all__ = (
'__version__',
'my_package_name'
)
import pkg_resources  # part of setuptools
__version__ = pkg_resources.get_distribution("mypackage").version
```
InformationsquelleAutor LightCC
-2
1. Utiliser un version.py fichier seulement avec __version__ = <VERSION> param dans le fichier. Dans le setup.py l'importation de fichiers de la __version__ param et mettre sa valeur dans la setup.py fichier comme ceci:
  version=__version__
2. Une autre façon est d'utiliser juste un setup.py fichier avec version=<CURRENT_VERSION> - le CURRENT_VERSION est codé en dur.
Car nous ne voulons pas modifier manuellement la version dans le fichier à chaque fois que nous créons une nouvelle balise (prêt à la sortie d'une nouvelle version du package), on peut utiliser la suite..

Je recommande fortement bumpversion paquet. Je l'ai utilisé pendant des années pour incrémenter la version.

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

Vous devez utiliser un petit script comme ça à chaque fois que vous croiserez un version:
```
bumpversion (patch|minor|major) - choose only one option
git push
git push --tags
```
Puis ajouter un fichier par repo 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 version.py fichier, comme il a été suggéré dans d'autres posts et mise à jour de la bumpversion fichier comme ceci:
  [bumpversion:file:<RELATIVE_PATH_TO_VERSION_FILE>]
- Vous doit git commit ou git reset tout dans votre pension, sinon vous obtiendrez un sale repo erreur.
- Assurez-vous que votre environnement virtuel inclut le package de bumpversion, sans cela, il ne fonctionnera pas.
- Désolé pour le retard, veuillez vérifier ma réponse ^^^ - notez que vous devez git commit ou un git reset tout dans votre pension et assurez-vous que votre environnement virtuel inclut le package de bumpversion, sans cela, il ne fonctionnera pas. L'utilisation de la dernière version.
- Je suis un peu confus au sujet de ce que la solution est suggéré ici. Êtes-vous recommander un suivi manuel de la version avec version.py, ou de suivi avec bumpversion?
- Je suggère à l'aide de bumpversion, ne jamais utiliser de manuel de contrôle de version. Ce que j'ai essayé d'expliquer, c'est que vous pouvez directement bumpversion de mettre à jour la version en setup.py fichier ou encore mieux de l'utiliser pour mettre à jour le version.py fichier. C'est une pratique plus courante pour mettre à jour le version.py fichier et de prendre le __version__ param valeur dans le setup.py fichier. Ma solution est utilisée en production et c'est une pratique courante. Note: juste pour être clair, à l'aide de bumpversion dans le cadre d'un script est la meilleure solution, le mettre dans votre CI et il sera en fonctionnement automatique.
InformationsquelleAutor Oran
-3

Si vous utilisez CVS (ou RCS) et qui souhaitent 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 sera substitué pour vous par CVS.)

Cela vous donne une version imprimable et une version info 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)
```
- Ce fichier vous recommander d'économie d'économie d' __version__ pour? Comment incrémenter le numéro de version de cette solution?
InformationsquelleAutor Martin Ibert

Vous devez vous connecter pour publier un commentaire.

De manière Standard pour intégrer la version en python package?

Au Niveau Du Module Dsous Noms

Réécrit 2017-05

Vieille solution

Comment cela fonctionne:

Détails:

Makefile

versionbump.py

init.py

setup.py

À l'aide de `setuptools` et `pbr`

En temps réel version actuelle

La mise à jour de la version