Poetry: Support automatic versioning setuptools_scm-style?

[madig]

Hi! I'm trying out different packaging solutions because I want to use pyproject.toml. Poetry looks nice.

What I'm missing is something like setuptools_scm that lets me ignore the version variable entirely and instead computes it from the git tag. That makes it possible to not litter the commit stream with version-bump commits and release a new version simply by tagging it in GitHub/GitLab.

What do you think?

[escaped]

Another tool which i often use is vcversioner. Might be helpful for inspiration :)

[madig]

Another nice automatism is that if you install a non-tagged build, it will automatically add a git-version-tag like 1.0-dev2-hash for signifying that this is using code 2 commits away from 1.0.

[webknjaz]

Add https://github.com/Changaco/setuptools_scm_git_archive to the list :)

[kevinkjt2000]

:+1: for something like setuptools_scm.

I find that automated/manual commits of version bumps often lead to tiny annoying conflicts in branches and benign ignore-this-auto-commit rules on CI servers. These problems disappear when _version control_ is tracking the version.

Perhaps, some form of plugin capability for overriding the version string dynamically with arbitrary python code is all that is needed here? Then anyone would likely be able to choose whichever version computation tool that they desire. Be that setuptools_scm, vcversioneer, or something else.

I am contemplating taking this on as my first contribution to this project, so please chime in with any helpful tips or design ideas if you have them. Hopefully tacking in the name of a python class to run later in the version field of the toml file would not be too hard. What would others expect here?

[webknjaz]

@kevinkjt2000 sounds good just as you suggest. I was thinking to do such contribution myself, just haven't had time to actually start that. I'm using setuptools-scm quite a lot, so feel free to ping me for review once you get at least a WIP PR started :)

[webknjaz]

@kevinkjt2000 hey have you started working on anything?

[kevinkjt2000]

With the American holiday ending, I was planning on starting this week. I
have not yet done anything other than setup the dev environment and run the
tests.

On Sun, Nov 25, 2018, 04:04 Sviatoslav Sydorenko <[email protected]
wrote:

@kevinkjt2000 https://github.com/kevinkjt2000 hey have you started
working on anything?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sdispater/poetry/issues/140#issuecomment-441428774,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD6KcjJDTwi5I3PbTCoebpMyXRrLQs7kks5uymsSgaJpZM4UNl9A
.

[webknjaz]

Oh.. So I've been poking around the source during last hour and now have something close to PoC. I'll send a PR to share that.

[kevinkjt2000]

Sweet! That's great news!

On Nov 25, 2018 09:08, "Sviatoslav Sydorenko" [e-mail]
wrote:

Oh.. So I've been poking around the source during last hour and now have
something close to PoC. I'll send a PR to share that.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sdispater/poetry/issues/140#issuecomment-441447187,
or mute
the thread
https://github.com/notifications/unsubscribe-auth/AD6Kck36prjRccPZtmQn1k9QwMn11klLks5uyrJkgaJpZM4UNl9A
.

[webknjaz]

But now it's more like a dirty patch, I'd like to have some feedback on what to do better architecturally.

[webknjaz]

Check it out: https://github.com/sdispater/poetry/pull/672

[sdispater]

This will not be integrated in Poetry by default but with the upcoming plugin system (see https://github.com/sdispater/poetry/issues/693#issuecomment-443763240) it will be possible to add it via plugins.

[jonathanunderwood]

it looks like all of the issues and PRs wrt to this feature have been closed without it being implemented. I could create a new issue, but I think it would be better to re-open this one.

[webknjaz]

This one is still open https://github.com/sdispater/poetry/issues/693#issuecomment-443763240

[jonathanunderwood]

This one is still open #693 (comment)

That one is for the plugin framework, not the setuptools_scm like functionality.

[webknjaz]

Yes, but the idea is to build it as a plugin once it's possible. And I'll do it.

[reece]

Please be sure to leverage setuptools_scm. It supports multiple SCMs and has worked well for me for years. I think that I've seen the authors post elsewhere about helping adapt to build frameworks like poetry.

[webknjaz]

@reece I did submit a PoC using setuptools_scm earlier and am planning to use it once it's possible to write a plugin for that.

[mtkennerly]

In the meantime while the plugin system is in progress, I ended up writing a non-setuptools-dependent library to help with doing this, Dunamai, so that you can run poetry version $(dunamai from git) to set the version. I hope that it could be a good basis for a plugin too since it doesn't have any setup.py baggage associated with its implementation.

[ssbarnea]

Any updates on this? I find the lack of scm versioning support a real deal-breaker from adopting poetry. Popular solutions like pbr and setuptools_scm made not ever want to spam commit count with version string bumping.

[madig]

The roadmap (https://github.com/python-poetry/poetry/issues/1856) says the prerequisite plugin system is slated for 1.1.

[ssbarnea]

Thanks. Changed my watching to "releases only", so I will know when to look back at poetry. Sadly that I ruled out flit too just before testing poetry for reasons like forcing me to rename the lib folder to src. If it would be about some personal project made over the weekend it would not be a problem but when you think about these for established projects, such changes become real problems. I am afraid that 2020 may not prove the year the python packaging was fixed, but there is still hope, 11 more months to go.

[mtkennerly]

@ssbarnea, you may want to try this pseudo-plugin I made for dynamic versioning: https://github.com/mtkennerly/poetry-dynamic-versioning . It's super hacky, but it works :D

[gsemet]

Hi. I would like to work on migrating my current module package pattern (pipenv+pbr) to a more modern solution like poetry. I like automatic versionning pbr does, I really wish a dynamic versionning lands into poetry some day (either built-in, or a plugin). This would be really useful if this plugin be in-virtualenv (not system plugin all users should install)