access
access copied to clipboard
fix version names in docs
@jGaboardi, ever since the update to versioneer (#39), I noticed that the versions listed in the docs show up weird -- like 0+untagged.1.g109a527:
Could you either advise how to fix this with a new tag, or do so and mention me?
Seems like no initial tag was ever made. I would suggest v0.0.1. When you are ready to create the tag from you machine do:
git tag -a v0.0.1 -m v0.0.1
then
git push upstream v0.0.1
OK, thanks. I think we were at 1.1.8 on the old naming via the py files, so I'll start at 1.1.9.
Hey @jGaboardi, the release build failed --
https://github.com/pysal/access/actions/runs/4683952297/jobs/8299566391
It seems like versioneer was set up for master whereas the repo was switched over to main?
Is it as simple as find/replacing s/master/main/g/ in versioneer.py?
No, the failure is coming from the tools/gitcount.ipynb notebook. This is failing because the first line of __init__ no longer contains the version. The solution I used previously was to replace the # get __version__ cell with:
# get __version__
%run ../access/_version.py
then add another cell
__version__ = get_versions()["version"]
Hey @jGaboardi, I noticed that we still have the weird versions in the docs --
I had pushed a tag long ago, and #47 fixed the other issue noted above.
It looks like the docs build was 'fine" at that time --
https://github.com/pysal/access/actions/runs/4909247529
I just tried making a release from that v1.1.9 tag, but perhaps I need to do something else to trigger the build?
I'm not familiar with versioneer or the current doc setup; do you have other ideas of what to check?
I will give it attention over the weekend, if that's OK. Across the ecosystem we have been a bit fluid recently with adopting improved infrastructure. For example, swaping out setup.py for pyproject.toml, versioneer for setuptools_scm, etc. Right now @weikang9009 and I are in the process of modernizing giddy in this fashion; including updating docs actions.
xref #21