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]

👍 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 ***@***.*** 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 <#140 (comment)>, 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" <notifications@github.com> 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 <#140 (comment)>, 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: #672

[sdispater]

This will not be integrated in Poetry by default but with the upcoming plugin system (see #693 (comment)) 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 #693 (comment)

[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 (#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)

[jeriox]

hey everyone, just came across this as we'd also love to use this feature.
As #3733 has been merged 4 days ago, it should now be possible to build such a plugin. Is anyone of you still planning on doing so?

[ssbarnea]

Not planning to do it myself but I am watching the ticket. I decided to delay trying poetry again until this aspect is addressed.

[mtkennerly]

@jeriox I'm planning to update poetry-dynamic-versioning to use the official plugin system as soon as the next Poetry release is available.

[jeriox]

@mtkennerly great! looking forward to trying it out then.

[WhyNotHugo]

@mtkennerly Will that change mean that poetry-dynamic-versioning would no longer need to be installed on the system python?

[mtkennerly]

@WhyNotHugo That's correct. You would just use the new poetry plugin add command.

(I was waiting for 1.2.0, but since there's a 1.2.0a2 now, I should probably go ahead and look into making an alpha version of the plugin as well.)

[WhyNotHugo]

I'd be very happy to start testing that, it's the one thing keeping me from migrating a bunch of projects over to poetry.

[mtkennerly]

@WhyNotHugo Thanks, I appreciate that! I'm currently having some issues, but I can tag you on mtkennerly/poetry-dynamic-versioning#39 when I work through the problems in #4366.

[WhyNotHugo]

Following both 👍

[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.