use setuptools_scm during install

[2bndy5]

I've been trying to hold off on this because it will slow the installation of this action in the docker env. But, If we decide to start distributing the python executable script to pypi, then using setuptools_scm will automatically update this action's version during install.

Uploading bdist_wheels to pypi will make installing via pip a little quicker, and this action's version number will be already set when the wheel is uploaded to pypi.

[shenxianpeng]

So I guess after this changes when we draft or create a new release, there is a release workflow can automatically update version from setup.py, commit the changes, build and upload the package to pypi then tag the latest commit to v1.
Please correct me if I am wrong.

[2bndy5]

We (or rather you) will still manage the tags. The setuptools_scm module will only get the latest tag (via git) and use that as the version number whenever we make a distribution, like so:

python setup.py bdist_wheel

The same happens when we install the pkg from source

python -m pip install .

If we build or install on a non-tagged commit, then the latest tag will be appended with info to show the difference between releases. For example: If the latest tag is v2.0.0, and there have been 3 commits since that tagged commit, then the version number used will be v2.0.0.post1.dev3 (translates to 1^st "post-release" at 3^rd commit since v2.0.0). However, pypi sees v2.0.0.post1.dev3 as a "pre-release", so pip would still install the latest "stable" release (pre-release versions need to be specified explicitly).

[shenxianpeng]

That sounds great 👍

[shenxianpeng]

I have used setuptools_scm in clang-tools-pip, and released the package to PyPI automatically. No longer need to manually update the version in setup.py.

[2bndy5]

Pretty cool isn't it?

I can make some modifications so that we can publish pre-releases to test-pypi... Pypi (& test-pypi) don't like it when the version name/number uses part of the commit sha. By default, setuptools_scm uses the commit sha in the version if the commit is not a tagged commit.

[shenxianpeng]

Very cool! So I used a local_scheme called no-local-version

https://github.com/cpp-linter/clang-tools-pip/blob/a63ca48822d0e3092686f26ec40162f75e936b9b/setup.py#L17

[2bndy5]

Yep, that's part of the solution. The rest of it is more like
https://github.com/jbms/sphinx-immaterial/blob/bf169751fba59362bcd06da96bfa65b2728cbbae/setup.py#L193-L200

[2bndy5]

I've got this working the same as it is in clang-tools-pip project.

@shenxianpeng should we be publishing to pypi using the name "cpp-linter-action"? I currently have it set to "cpp-linter", but I'm afraid that might be confused with cpplint.

[shenxianpeng]

In this setup.py, you named the package as "cpp_linter", maybe we called "cpp-linter" better than "cpp-linter-action".
If we called "cpp-linter-action" on pypi, it looks like it's a GitHub action.

For example clang-tools-pip project, the package on pypi we called "clang-tools", not "clang-tools-pip".

[2bndy5]

cpp-linter-action/pyproject.toml

Line 6 in d802afb

name = "cpp_linter"

I didn't notice the _ here. You're correct, it should be -.