di / bump Goto Github PK

Do you think a bump show sub-command would be nice to have? So it shows the current version number?

Or maybe it would just be a flag, like:

bump --show

Current Travis-CI config is here: https://github.com/di/bump/blob/master/.travis.yml

Hi

Is this still maintained? Are you looking for anyone to help you with this?

I was looking into this topic and your project seems to be the most sane one. Bump2version looks bloated as hell, the rest aren't even maintained anymore.

Using https://github.com/pypa/packaging would let us correctly parse versions in every case.

Assume that I have the following version right now:

0.1.11-foo+dev

If I bump without any arguments, e,g,

bump

then I get

0.1.12-foo+dev

I would have assumed that it would remove the last parts. If that is intentional, how can I bump the local and pre tags away?

Problem:

• When publishing the application, remember to change the major/minor version, but when publishing a patch, you may forget to update the patch version,
• Developers are sometimes lazy and don't bump up the version for every patch.

Solution:

By adding the command bump --pypi during the build and release process, the script will take the number from pypi.org and increment it by one, patch number.

Example:
Local version 1.3.0, pypi version 1.4.0, after the bump --pypi 1.4.1.

This only leaves the user with the responsibility of keeping the numbers for major / minor.

Proposition of the change in PR #19

Likely need to solve #2 first.

Hey first off thanks for the tool, found it very useful over the years. Thanks for picking it up and maintaining it!

I've found an issue with this when running with 2.7.15

~/Work/vault-provisioner
vp ❯ python --version
Python 2.7.15

~/Work/vault-provisioner
vp ❯ bump
Traceback (most recent call last):
  File "/Users/Damien/.virtualenvs/vp/bin/bump", line 11, in <module>
    sys.exit(main())
  File "/Users/Damien/.virtualenvs/vp/lib/python2.7/site-packages/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/Users/Damien/.virtualenvs/vp/lib/python2.7/site-packages/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/Users/Damien/.virtualenvs/vp/lib/python2.7/site-packages/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/Users/Damien/.virtualenvs/vp/lib/python2.7/site-packages/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/Users/Damien/.virtualenvs/vp/lib/python2.7/site-packages/bump.py", line 126, in main
    major = major or config.getboolean('bump', 'major', fallback=False)
TypeError: getboolean() got an unexpected keyword argument 'fallback'

I've had a ponder at the code but no ideas right now

Click is currently at version 7.1.2.

The setup.py requires a version less than 7.

Should this requirement be dropped/changed in some way?

In the code we can see:

        patch = patch or config.getboolean("bump", "patch", fallback=True)

which means that patch will be true unless specified.

This means that if the current version is 1.1.1 and you do bump --minor the new version is 1.2.2 instead of 1.2.1

Is this behavior intended? If so, why?

If you are using Poetry to manage your package, and have a private poetry source, any package dependencies with a version are bumped incorrectly.

pyproject.toml:

[tool.poetry]
name = "my-project"
version = "1.0.1"

[[tool.poetry.source]]
name = "private"
url = "https://my-domain.com/pypi/simple"
secondary = true

[tool.poetry.dependencies]
my-custom-package = {version = "^2.1.5", source = "private"}

Then when bumping the project version correctly bumps to 1.0.2, but the custom package dependency is also bumped to the same version

$ bump pyproject.toml
1.0.2

$ diff pyproject.toml pyproject.toml-orig
3c3
< version = "1.0.2"
---
> version = "1.0.1"
11c11
< my-custom-package = {version = "1.0.2", source = "private"}
---
> my-custom-package = {version = "^2.1.5", source = "private"}

bump currently reads from a .bump file or from setup.cfg -- it would be cool if it could (additionally) read its settings from a [tool.bump] section within pyproject.toml!

It's my understanding that similar developer tools have done this on an opt-in basis with an extra, so pip install 'bump[toml]' could be used to enable this for interested users while leaving the default installation's behavior alone.