peotry version doesn't bump the value in __version__

[ksamuel]

$ poetry version 0.1.1
Bumping version from 0.1.0 to 0.1.1
$ grep version pyproject.toml 
version = "0.1.1"
$ grep version */__init__.py
src/__init__.py:__version__ = '0.1.0'
$ poetry --version
Poetry 0.9.0

I don't know if it's intended or not. A way to do that safely is to parse the root __init__.py, detect __version__, back it up, extract the ast, bump the version string and replace it, then extract the new ast and compare the result. If both ast are the same, except for the version, the file semantics have been preserved. Otherwise, rollback the change and display an error message stating we can't bump the version safely.

[sdispater]

At the moment this is not possible no.

poetry version will only bump the version in pyproject.toml. This is not intended and that's definitely something I plan on adding.

[Victor-Savu]

I really wish that the version field in the .toml ended up superseding the __version__ string in __init__.py. This would reduce the burden of having to keep multiple places in the code in sync.

[ksamuel]

Setuptoos has solved this problem for 2 years: https://setuptools.readthedocs.io/en/latest/setuptools.html#configuring-setup-using-setup-cfg-files You can put all metadata in setup.cfg instead of setup.py. For the version, you can specify: version = attr: src.__version__ Which will load the version from the package directly, this way you have it in one place only. It works as long as you has setuptools >= 30.3 (current version is 38.5.1) so basically any package with a setup.py can already benefit from that without using any additional tool.   Le 27/05/2018 à 07:28, Victor-Nicolae Savu a écrit :

…

I really wish that the |version| field in the |.toml| ended up superseding the |__version__| string in |__init__.py|. This would reduce the burden of having to keep multiple places in the code in sync. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#144 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANivj7pFmuXBG79h1VOEG9_SM0V4Tj1ks5t2jl7gaJpZM4UO8xi>.

[Victor-Savu]

@ksamuel Thanks for pointing that out! I use that setuptools feature as well :) It feels a bit backwards that it needs to be referenced in two places, but I suppose that is just my ignorance with respect to the benefits of having programmatic access to the version of a package. I can kind of imagine a scenario, but I have never seen a real-world example of where that was used (again, it's just my inexperience, I am not criticizing such a practice :) )

[jgirardet]

you may use that

import toml
from pathlib import Path

def get_version():
   path = Path(__file__).resolve().parents[1] / 'pyproject.toml'
   pyproject = toml.loads(open(str(path)).read())
   return pyproject['tool']['poetry']['version']

__version__ = get_version()

[ksamuel]

Now that doesn't work when the file system is not available, or when the project file is not shiped. Le 27/05/2018 à 20:21, jgirardet a écrit :

…

you may use that |import toml from pathlib import Path def get_version(): path = Path(__file__).resolve().parents[1] / 'pyproject.toml' pyproject = toml.loads(open(str(path)).read()) return pyproject['tool']['poetry']['version'] __version__ = get_version() | — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#144 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANivtdMQKQ53fmYDl0RaC2Wh-ZviBhlks5t2u6TgaJpZM4UO8xi>.

[digitalresistor]

Personally I think storing a __version__ in __init__.py seems duplicative. You can use pkg_resources to retrieve the version for the installed package using:

pkg_resources.get_distribution("packagename").version

If used with:

poetry develop

This will work even when developing locally (it requires the egg-info).

[ksamuel]

It doesn't work with vendoring, or anything using sys.path.append. And it's way harder to type in an interpretter. Who remember that ? Le 30/05/2018 à 19:54, Bert JW Regeer a écrit :

…

Personally I think storing a |__version__| in |__init__.py| seems duplicative. You can use |pkg_resources| to retrieve the version for the installed package using: |pkg_resources.get_distribution("packagename").version | If used with: |poetry develop | This will work even when developing locally (it requires the egg-info). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#144 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANivn9NPZz_2OgTFG4OPozzcHa3zB_xks5t3tzvgaJpZM4UO8xi>.

[madig]

Using pkg_resources also introduces an install-time dependency on setuptools, no?

[vlcinsky]

Currently workaround can be to use bump2version package (maintained fork of bumpversion).

For my package poetry_demo with default poetry_demo/__init__.py and tests/test_poetry_demo.py content I have following .bumpversion.cfg file (use of setup.cfg file name is also possible):

[bumpversion]
current_version = 0.1.0
commit = True
tag = True

[bumpversion:file:pyproject.toml]
search = version = "{current_version}"
replace = version = "{new_version}"

[bumpversion:file:poetry_demo/__init__.py]
search = __version__ = '{current_version}'
replace = __version__ = '{new_version}'

[bumpversion:file:tests/test_poetry_demo.py]
search = __version__ == '{current_version}'
replace = __version__ == '{new_version}'

To bump the version:
$ bump2version patch
and all version instances will become 0.1.1.

Provided configuration will also commit the modification and create tag. This (and many more features) are configurable.

A little problem is, that currently it requires extra configuration file .bumpversion.cfg, but there is an issue c4urself/bump2version#42 planning to use pyproject.toml

The tool seems rather mature, has many features and is used for quite some time.

To implement bumping versions in poetry, it may serve at least as nice inspiration.

[pmav99]

Apart from poetry itself, __version__ bumping should be implemented in the scaffold project that is being created by poetry new too. In that particular case, I think it would make sense to stick to the standard library instead of adding a toml depenedency, so something like this could be used:

import configparser

parser = configparser.ConfigParser()
parser.read("pyproject.toml")
__version__ = parser["tool.poetry"]["version"]

__all__ = ["__version__"]

[madig]

One thing to keep in mind with the automatisms like that is that they will access the disk on importing the library. Code execution on import is not that uncommon in Python, but not desireable to keep down import times and minimize side effects.

Does the pyproject.toml file even ship with wheels?

[digitalresistor]

@pmav99 you can't do that unless you also ship pyproject.toml with your WHEEL for instance.

[MRigal]

I also think this is something very important.

Another example is when you integrate it with a tool like Sentry, you are willing to know for which version it applies. Currently, I couldn't find a proper way to include it except writing a __version__ string in the __init__.py

[willingham]

Depending on your build process, one solution is to use a shell script for bumping the version instead of running poetry version explicitly. I prefer using makefiles, so I added these two rules to mine to solve this problem.

poetryversion:
	poetry version $(version) 
	
version: poetryversion
	$(eval NEW_VERS := $(shell cat pyproject.toml | grep "^version = \"*\"" | cut -d'"' -f2))
	sed -i "" "s/__version__ = .*/__version__ = \"$(NEW_VERS)\"/g" x12_utils/__init__.py
	

This command can be run as follows: make version=1.2.3 version

If you dislike specifying the version(type) that way, this could just as easily be implemented as a shell script such as:

poetry version $1
new_vers=$(cat pyproject.toml | grep "^version = \"*\"" | cut -d'"' -f2)
sed -i "" "s/__version__ = .*/__version__ = \"${new_vers}\"/g" x12_utils/__init__.py

[NargiT]

In my case reading from pyproject.toml does not make sense as I ship a CLI and myapp version has to be able to answer to this question without pyproject.toml.

[JnyJny]

I would also like to see poetry version bump the version in:

• pyproject.toml
• <package_name>/__init__.py
• tests/*.py # any tests which have a version literal in them

Since pyproject.toml is already handled, it seems something like using astor might be a good choice for safely modifying python source.

[JnyJny]

I've prototyped this feature and would like some feedback. I consider this an 80% solution that will make most people happy.

In addition to updating pyproject.toml, the new command will update version strings in specific python contexts; specifically assignments and comparisons. It will also do a global replacement on text files with specific suffixes:

• *.[mM]*[dD]* for Markdown
• *.[rR][sS][tT] for ReStructured Text
• *.[tT]*[xX][tT] for plain text files

The updated command syntax is:

poetry version <rule> [--dry-run]

[dmontagu]

@JnyJny If I understand correctly, your current approach for text files is just replacing the version string wherever it occurs in any file with a matching extension. I feel like that has a relatively high potential for false positives, e.g. if you list required versions for dependencies anywhere in your documentation.

I haven't dug into your implementation for python files at all but in principle I think it would be less likely to cause problems there (given you can analyze code more deeply than documentation, and code is less likely to include unrelated version strings).

Also, I think this would be a nice quality-of-life improvement even if it was only applied to __init__.pys (and given the potential for false positives, that may be preferable anyway).

[ttamg]

Reading this thread, it seems to me that for now it's best to keep both the pyproject.toml version and the package.__version__.

So my process is just to stop me accidentally forgetting to update one.

I've got a simple test that checks that those two are in alignment and fails if not.

import toml
from pathlib import Path
import my_package

def test_versions_are_in_sync():
    """Checks if the pyproject.toml and package.__init__.py __version__ are in sync."""

    path = Path(__file__).resolve().parents[2] / "pyproject.toml"
    pyproject = toml.loads(open(str(path)).read())
    pyproject_version = pyproject["tool"]["poetry"]["version"]

    package_init_version = my_package.__version__
    
    assert package_init_version == pyproject_version

Seems to do the job without having to resort to some of the convoluted solutions above which may be hard to maintain

[nikhiljohn10]

Here is my suggestion.

First, poetry new package create __init__.py as an empty file. In addition, create __version__.py next to it. But the content is:

#v0.1.0

( its a hashtag. pun intended. xD )
Anyway,

1. Since it's a python file, it will be packed while building the package.
2. It is safe to edit by poetry version along with pyproject.toml
3. Even a simple script like VERSION="0.1.0"; echo "#v$VERSION" > package/__version__.py can bump version
4. The #v will be the marker for the regular expression to search and find it even if the file contains any other content.

The following code can be used inside setup.py to obtain the version

#!/usr/bin/env python3

import re
from pathlib import Path

HERE = Path(__file__).parent
version_file = HERE / "CloudflareAPI/__version__.py"
version_file = version_file.resolve(strict=True).read_text()
version = re.search(r'#v(.+)', version_file).group(1)
print(version)

It can also be used in test files where the version is required.
(I do not feel like using importlib.metadata)

Any thoughts?

[deftio]

I'm coming in here in Jan 2022, and I'm actually just looking for the canonical answer. Where is the single source of truth spot to put the version string (or where in the docs as poetry version doesn't seem to be the place).

I ran across this:
https://pythonrepo.com/repo/tiangolo-poetry-version-plugin-python-package-dependency-management

which seems to show that others have this issue and are solving it with plugins but if I missed this a pointer in the right direction is appreciated.

[adam-grant-hendry]

I'm coming in here in Jan 2022, and I'm actually just looking for the canonical answer. Where is the single source of truth spot to put the version string (or where in the docs as poetry version doesn't seem to be the place).

I ran across this: https://pythonrepo.com/repo/tiangolo-poetry-version-plugin-python-package-dependency-management

which seems to show that others have this issue and are solving it with plugins but if I missed this a pointer in the right direction is appreciated.

I'd also like some clarification. I'm not sure what to follow. There are still several different plugins floating around:

1. https://github.com/bulv1ne/poetry-bumpversion
2. https://github.com/tiangolo/poetry-version-plugin
3. https://github.com/mtkennerly/poetry-dynamic-versioning

I'm fine to use importlib.metadata, so long as I can also use it for local packages I am developing (develop = true). Has anyone tested this?

[adam-grant-hendry]

If you package your project, the version number is integrated into it. Then use importlib_metadata (since python 3.8 as build-in importlib.metadata) to access the version number during run time if needed.

Does this work for packages in development mode? Can you point me to tests?

[deftio]

Well FWIW in jsonvice I solved the problem by adding:

and this in the master source code file:

import pkg_resources # part of setuptools
version = pkg_resources.require("jsonvice")[0].version

Now there is only one place the version is only specified in pyproject.toml and the string is available at runtime so the program can self-report its version number when queried.

[monim67]

I have published poetry-bumpversion plugin to update version in other files when poetry upgrades the package version. To update __version__ just install the plugin and add the following to your pyproject.toml file.

[tool.poetry_bumpversion.file."your_package/__init__.py"]

[svaningelgem]

FWIW I'm using this:

import importlib.metadata
__version__= importlib.metadata.version('<package name>')

Works fine 👍

[NargiT]

I also switched to importlib.metadata
But I had to change my release workflow, before it was fully automated as I was able to choose in advance the version number during development.

My Take Away for importlib.metadata

Pros:
No more version number in files
No more required to bump/commit/push a new version during development or release workflow
Version is only available in git tags and inside package
relatively easy to automate for patches releases even with branch protection

Cons:
hard to automated for minor and major release

Bonus

Here is the github action snippet code to trigger a package publish for version 1.0.0
My Workflow

• develop
• create pr
• merge
• release

I use manually gh cli gh release create 1.0.0 --generate-notes or directly from github.com (it generates the same event)

name: publish package

on:
  push:
    tags:
    - '**'

jobs:
  publish:
    runs-on: ubuntu-20.04
    steps:
    - uses: actions/checkout@v3
      name: Checkout code
    - uses: actions/setup-python@v4
      name: Set up Python
      with:
        python-version: '3.10'
    - name: Install tools
      run: |
        pip install --upgrade pip
        pip install poetry
    - name: Publish distribution 📦 to PyPI
      run: |
        poetry config repositories.pypi ${{ secrets.PYPI_REPOSITORY }}
        poetry version ${{ github.ref_name }}
        poetry publish --build -r pypi -u ${{ secrets.PYPI_PUBLISH_USERNAME }} -p ${{ secrets.PYPI_PUBLISH_TOKEN }}

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.