Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FR] Target segment position bump custom callable/hook support #773

Open
webknjaz opened this issue Oct 27, 2022 · 2 comments
Open

[FR] Target segment position bump custom callable/hook support #773

webknjaz opened this issue Oct 27, 2022 · 2 comments

Comments

@webknjaz
Copy link
Member

So I've been thinking about making an automation with Towncrier where setuptools-scm would be made aware of which segment should be updated when guessing the next version.

I know there are multiple strategies available, but they are all pretty much hardcoded. What I want is to keep using a strategy that's already available but be able to tell setuptools-scm whether the next guessed version would bump MAJOR, MINOR, PATCH or whatever segment bit.

What I was imagining is a sort of a setting that would allow pointing at an arbitrary callable (typically in-tree) that would return an integer telling setuptools-scm which part of the version needs to be bumped.

So API-wise, it'd align with https://github.com/pypa/setuptools_scm#extending-setuptools_scm. Let's say the name could be setuptools_scm.get_bump_segment_position.
Then, the end-users could provide a custom implementation of the version segment to be bumped detection. It'd look something like this:

MAJOR_SEGMENT = 1
MINOR_SEGMENT = 2
MICRO_SEGMENT = 3

def get_bump_segment_position():  # dunno if it needs to access any context through args
    ... # detect what types of the Towncrier fragments are present on disk
    if <there's some breaking changes>:
        return MAJOR_SEGMENT
    if <it's a new feature>:
        return MINOR_SEGMENT
    if <it's misc/docs/internal>:
        return MICRO_SEGMENT
    return None  # delegate the auto-detection back to setuptools-scm

I think this design would provide enough flexibility to the end-users while not forcing them to revert to using the legacy setup.py or an in-tree PEP 517 backend wrapping setuptools, for example.

@RonnyPfannschmidt
Copy link
Contributor

I believe we need a expansion of the parse concept, so that towncrier /Scriv integration can provide worktree details

@webknjaz
Copy link
Member Author

I'm not sure these tools should only interact with parse directly...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants