support defining callable get_version kwargs in in pyproject.toml tool.setuptools_scm

[graingert]

Currently when using the non-legacy pyproject.toml setuptools_scm configuration, you are unable to define inline callable version schemes - you're forced to publish a package on pypi and use its entry point. setuptools_scm should provide a declarative alternative to:

#setup.py
import setuptools

def myversion():
    from setuptools_scm.version import get_local_dirty_tag
    def clean_scheme(version):
        return get_local_dirty_tag(version) if version.dirty else '+clean'

    return {'local_scheme': clean_scheme}

setup(
    ...,
    use_scm_version=myversion,
    ...
)

for example:

# pyproject.toml

[tool.setuptools_scm]
local_scheme = "scm_schemes:clean_scheme"

# scm_schemes.py
from setuptools_scm.version import get_local_dirty_tag

def clean_scheme(version):
    return get_local_dirty_tag(version) if version.dirty else '+clean'

[RonnyPfannschmidt]

in the setuptools world its perfectly valid to just use setup.py for that

so im treating this one as low prio, but im happy to review a contribution

[RonnyPfannschmidt]

closing as wontfix

[ahopkins]

Why wontfix? It seems a legit request and a feature that is missing. Your docs themselves point out that setuptools is considered legacy.

[RonnyPfannschmidt]

@ahopkins things changed a bit as more and more static metadata stuff is incoming

im still not convinced its a good idea to support random imports for the schmes, but im happy to accept a pr

[graingert]

@ahopkins things changed a bit as more and more static metadata stuff is incoming

if setuptools_scm wrote to the pep621 version field in a pre-commit hook that would fix my usecase here

[hugovk]

This is my use case, to get a valid PyPI version to upload (untagged) dev versions to Test PyPI:

# setup.py
from setuptools import setup


def local_scheme(version):
    """Skip the local version (eg. +xyz of 0.6.1.dev4+gdf99fe2)
    to be able to upload to Test PyPI"""
    return ""


setup(
    use_scm_version={"local_scheme": local_scheme},
)

[RonnyPfannschmidt]

@hugovk there's a case of making that one a builtin

[MarkKoz]

https://github.com/dolfinus/setuptools-git-versioning supports this feature. However, it requires setuptools.build_meta:__legacy__ to be able to import the package that contains the version callable. I'm not sure if setuptools_scm could avoid that or if setuptools even has any planned workaround for us once they get rid of __legacy__ (besides just suggesting to use setup.py instead).

[dbrasseur-aneo]

Since the usage of setup.py is deprecated, this case may become relevant again. For example, since setuptools_scm doesn't provide a way to add a modified hash information (turning it to int to be Pep440 compliant for example), we can only resort to a function call. But not having it inline is a real problem.

[RonnyPfannschmidt]

Mainline supports callable arguments, the 8.0 release will handle it better

[RonnyPfannschmidt]

@dbrasseur-aneo also please show the hack you have for making commits compliant, i wonder if it's feasible for inclusion under a indicative name

[dbrasseur-aneo]

@dbrasseur-aneo also please show the hack you have for making commits compliant, i wonder if it's feasible for inclusion under a indicative name

Honestly it's a horrible hack :

version.format_next_version(guess_next_version,"{guessed}" + f".dev{int(version.node[1:], 16)}")

It uses the truncated hash and converts it to an int. But it's not what i'd like to see/have. I can use the same trick with the branch name (through its truncated hash) to get another layer.

Ideally, although it may not be feasible with the git tooling, would be to have a format like :

{tag|guessed}.post{branch_number|PR_number}.dev{distance since start of branch}

Or anything better than .post or .dev That would allow different branches to be distinguishable and be with Pep440 compliant version (to send to the test PyPi for example) But PR number is specific to Gitlab or Github, I'm not sure about other kind of repositories that are based on Git. Branch number doesn't even seem to exist, but an equivalent would be great.

[RonnyPfannschmidt]

Well, build Tags are for that Metadata

They are intentionally local

The historic consensus is to use something like devpi or forge local pypi indexes to store such build artifacts

[RonnyPfannschmidt]

Ps, the post release is going to be deprecated for normal setuptools_scm automation, it's wrong to use it for the purpose setuptools_scm feeds