Creosote 4.0 heads-up

[fredrikaverpil]

Here's a list of stuff that would break backwards compatibility and bump creosote to v4.0. Might be good to try to consider all these things before releasing the next major version.

Also, I personally am not using creosote and therefore this is not a priority for me. I merely keep the lights on here.

So consider this a FYI and feel free to help out if you use creosote 😄

• Drop Python 3.8 support.
• Update type hinting for Python 3.9.
• Fix slew of basedpyright and typing warnings.
• Change release tagging to omit the v prefix or somehow make release-please workflow be able to accurately update .pre-commit-config.yaml.
• Hopefully get Python: add support for __about__.py googleapis/release-please#2433 considered, or potentially move to using __init__.py for storing the version (or just store the version in pyproject.toml).

[sanmai-NL]

@fredrikaverpil I suppose you want to reopen this?

I wanted to suggest looking at https://github.com/thebjorn/pydeps, which scans Python bytecode for imports, which may be faster than scanning package metadata.

[fredrikaverpil]

Thanks @sanmai-NL that's an interesting suggestion.

This project is more or less in maintenance mode and I'm not planning any major improvements other than keeping the lights on. So we'll see. I'm not currently planning any of this work - just really collecting all the stuff I've been thinking of doing but which would bump major.

[sanmai-NL]

@fredrikaverpil Even reducing the maintenance burden might in itself be an interesting goal. For example, what if you could leverage pydeps' output rather than adopting their approach.

[sanmai-NL]

@fredrikaverpil I don't see why maintainers are attracted to these simplistic bots...