Poetry: make `poetry version` work like `npm version`

[cjw296]

update

Please see @mattyclarkson 's comment below for what this issue should be!

---

• [X] I have searched the issues of this repo and believe that this is not a duplicate.

Issue

Interested to see what others feel about this. I've braino'ed poetry version a couple of times when I meant poetry --version. "version" is a noun in my head, and poetry inc_version would be more explicit.

However, I'm well aware this might just be me, so thought I'd ask/suggest here and see what others said :-)

[mattyclarkson]

This maps well to npm version

[cjw296]

Actually, that's not quite true, from chatting with a JS dev:

npm version outputs the current version of your project
npm version minor updates the third point
...etc...

I think that would be better for poetry too :-)

[playpauseandstop]

Run into same issue recently, as an npm user I expected the behavior from
https://github.com/sdispater/poetry/issues/629#issuecomment-439128806, when npm version call outputs the version of the package instead of increasing it, so I propose to change poetry version to work the same as npm version

[cjw296]

@mattyclarkson @abn - what do you think to @playpauseandstop 's suggestion. I like it :-)

[abn]

@cjw296 fwiw, I do not think such a change is warranted. The option --version follows the expectations set by all other options in poetry and version is a sub-command with a default behavior enacted on the project context. While poetry does share similarities with npm both these tools cater to different ecosystems with their own conventions and practices. Python command line tool options and arguments borrow heavily from conventions established by optparse and argparse. And this is anticipated quite naturally by developers working within the ecosystem I'd think. A change to this might help a few but hinder a lot more.

Speaking for myself at least, the behavior of poetry version as opposed to poetry --version is natural and expected. This should not be changed.

[mattyclarkson]

@cjw296 I sorta more meant that the command name mapped well, not the default operation. sorry to be unclear.

@abn they are different things?

| command | npm outcome | poetry outcome |
| --- | --- | --- |
| <tool> version --version | outputs tool version | outputs tool version |
| <tool> version | outputs project version information | bumps patch version |
| <tool> version patch | bumps project patch version and creates a commit | bumps project patch version number |
| <tool> version minor | bumps project minor version and creates a commit | bumps project patch minor number |
| <tool> version major | bumps project major version and creates a commit | bumps project major version number |

The only difference is that poetry defaults to bumping the minor version rather than outputting the current project version and npm/yarn create commits. I think that is acceptable; if a little bit unexpected when moving from npm/yarn.

Having said that, considering that poetry seems to be poised to be the npm/yarn for the Python world, it would make sense to use the years of development that has been poured into those tools. If we can be compatible, when people switch between tools it is less jarring. Obviously, there are somethings that just aren't going to be the same; they are different ecosystems. There will be similarities (version/ running scripts) though and it would make sense not to reinvent the wheel. npm/yarn do have some warts (see the prepublishOnly script situation) but generally work pretty well.

We have both JS devs and ML Python devs. Having the same workflow really helps. poetry almost does this.

[cjw296]

@mattyclarkson - your description is perfect, let me update the issue title and point to your comment...

[abn]

@mattyclarkson Just to be clear, I did not mean to allude that the purpose of the version sub-command in these tools serve different purposes but rather the tools sometimes cater to idiosyncrasies of the ecosystems they are a part of.

I, personally, have no objection to a change that updates the default behavior and in-fact do agree that having consistent behavior across environments is the way to go.

My comment was following from the issue description requiring a rename of the sub-command to inc_version. That, I think is not warranted.

[cjw296]

@mattyclarkson, @abn - great, sounds like we're all on the same page: keep poetry version but make it display the current project's current version, and add something to explicitly do a third point increment.

@sdispater - would you welcome a PR that made this happen?

[kbakk]

I think this issue deserves more thumb up's, given the update in the issue.

Right now I have to work around this by installing a toml library to read the pyproject.toml, and running a one-liner to get the project version. For anyone curious:

python -c 'import tomlkit; print(tomlkit.parse(open("pyproject.toml").read())["tool"]["poetry"]["version"])'

Since what @mattyclarkson suggests is a breaking change, putting it in the 1.0 release seems fitting.

[mofahead]

poetry bump major
poetry bump minor

[stephsamson]

1191 fixes this.