Add dynamic versioning

[keithchev]

This PR introduces dynamic versioning that infers the package version from the most recent git tag. This simplifies the release workflow by eliminating the need for a separate PR to increment a hard-coded version number in pyproject.toml or elsewhere. It also takes care of populating the __version__ attribute in the top-level __init__.py.

With this change, we can create and publish a new version simply by creating a new git tag containing the new version number, then calling make publish as before.

Another nice feature of this approach is that the generated version string will include flags if there are commits since the most recent git tag or if the repo contains uncommitted changes (neither of which should ever be the case when a new release is published, but there is no simple way to enforce this, so appending this information in the version string is a nice sanity check).

h/t to @ekiefl for pointing out that the package was missing a __version__ attribute, which motivated this PR.

[ekiefl]

I've never seen this, but I really like it.

Have you tested that it works? I tried installing from test PyPI but the highest version is 0.5.1, and doesn't have a version attribute.

It would be nice to confirm that this works:

make build

conda deactivate
conda deactivate
conda deactivate
conda deactivate
conda deactivate
conda env remove -y --name delete
conda create -y -n delete python=3.9
conda activate delete

# Untested
pip install dist/*tar.gz

# Move out of directory to not accidently import locally
cd ~
python -c "import arcadia_pycolor; print(arcadia_pycolor.__version__)"

[mezarque]

I'm really not familiar with most of poetry's functionality, but otherwise this seems like a useful change!

[keithchev]

Have you tested that it works? I tried installing from test PyPI but the highest version is 0.5.1, and doesn't have a version attribute.

Yeah, I tested it locally by checking that __version__ gets updated in the .gz build artifact. It's not possible to test-publish without a new version, because pypi doesn't allow the "dirty" version numbers that are generated when the package is built from a tag-less commit. For example, building on this PR results in a version "0.5.1.post3.dev0+0a49a94". I like this feature of the dynamic versioning and it makes sense that pypi disallows these versions, since it prevents accidentally publishing some random commit, but it does make testing the publishing command harder...

[ekiefl]

Left a comment you should feel free to take or leave.

Thanks for the intro to dynamic versioning.

[ekiefl]

I feel like this has been on our minds but since it hasn't yet been expressed yet, allow me to be first to say: this is chalking up to be a pretty robust publishing pipeline poster child that should be adaptable to other packages 🎊

[keithchev]

I feel like this has been on our minds but since it hasn't yet been expressed yet, allow me to be first to say: this is chalking up to be a pretty robust publishing pipeline poster child that should be adaptable to other packages 🎊

Thanks! It's slowly getting there, though it still feels v minimal compared to "real" packages (e.g. this which I think is pandas' actual build workflow, though it's hard to tell).