René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"setuptools-scm compatibility","articleBody":"### Description\r\n\r\nI have had a lot of success in the past with using setuptools-scm. One nice feature is that it can be used in a way where you have a single source of truth as to what version you are on (via a tag). However, some features that setuptools-scm does not help with are having a good way to walk users through commit message writing, and having logic for how to bump from version to version based on those commit messages. When trying to run projects for large user bases and varied programming experience, the extra help goes a long way to easing pain for developers.\r\n\r\n### Possible Solution\r\n\r\nIn a perfect world, I would be able to use both tools. One possibility might work like this:\r\n  If commitizen is unable to find a current version number using its config mechanisms, and it detects that setuptools-scm is in use (maybe by checking the pyproject.toml['build-system']['requires'] for setuptools-scm?), then it falls back to using setuptools-scm's get_version() for the current version number. I would also be happy with an explicit flag or config line to specify to run in \"setuptools-scm compatibility mode\".\r\n\r\n  It would also be required that bump not try to save the version number to the config file when it is in this compatibility mode, but instead recompute after tagging with an additional call to setuptools-scm get_version() function to update the current version stored in the config.\r\n    \r\nI would also be happy with a way to extend the behavior of bump, perhaps something like https://github.com/commitizen-tools/commitizen/issues/292 or some sort of other hooks for plugins might be useful for allowing people to extend this kind of functionality.\r\n\r\n\r\n### Additional context\r\n\r\npotential issues:\r\n\r\nIt would be pretty easy for someone to try to write versions from both commitizen and setuptools_scm to the same files. both tools try to do this automatically in many cases, so the potential for conflict is definitely there.\r\n\r\n### Additional context\r\n\r\nThanks so much for taking the time to read this, and, after the discussion, i am happy to work on some pr's. I also recognize that the ethos of commitizen and setuptools_scm is a bit different from each other, but, I hope that maybe both together makes for an even better development environment.","author":{"url":"https://github.com/jaustinpage","@type":"Person","name":"jaustinpage"},"datePublished":"2022-12-16T20:44:49.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":8},"url":"https://github.com/641/commitizen/issues/641"}