I notice that you closed this. Rather than update versioneer, we would be happy to have simpler code to achieve the same end if you would be interested in attempting that.

I don't know, Versioneer seems OK to me. Perhaps it's not worth using custom code instead. And there's Miniver is you want something smaller.

It's just that the update appears to be more complex than expected, I probably need to update a few other things first.

There is no reason to update versioneer unless it stops working. OTOH, it is over designed for our needs and could be replaced with a small amount of code. SciPy took a different approach. The only need is to order the wheel names correctly so that downloads from the nightly (development) repository get the latest version. It may also be the case that meson would work better with a simpler system. @rgommers Thoughts about meson?

The initial reason for me was to shut up this codespell warning:
unparseable ==> unparsable

Meson is a replacement for autotools, using it in a Python project also feels like overdesign.

It may also be the case that meson would work better with a simpler system. @rgommers Thoughts about meson?

It doesn't matter too much. We'll want to enable custom version strings, there are many Python packages that deal with this: versioneer, setuptools-scm, setuptools-vcs-version, etc. Most of them are a bit over-engineered, but I'm also not in a hurry to deal with that. We have versioneer now, let's stay with it for the time being.

I'm not keen to look at a huge diff like this in order to deal with a codespell warning, but if you want to merge @charris then that's fine too.

Is it worth looking at the diff in detail? At least the commit which copies/pastes Versioneer 0.26 is supposed to have been reviewed upstream, you could just check that I am committing the genuine Versioneer 0.26 code and not some code modified through error or malice:

• b6d94fa

The other two commits might be worth looking into:

• 2145d9e (re-apply previous patch to vanilla Versioneer)
• 2172528 (shows that upstream reviews/tests have not been thorough enough 😄)

Meson is a replacement for autotools, using it in a Python project also feels like overdesign.

There seems to be some implicit assumption here that using autotools is fine on its own, but in a python project is overdesign. I don't think I agree, though...

There are other problems with using autotools in a python project, primarily that autotools depends heavily on POSIX shell scripts and isn't easily portable to Windows, while python projects usually are portable to Windows.

The initial reason for me was to shut up this codespell warning:
unparseable ==> unparsable

Does codespell not have an option to exclude files or directories that contain third-party code, for which it is always inappropriate to suggest localized modifications unless those modifications fix runtime bugs?

Sure, codespell does have such an option. Additionally, it can be added to pyproject.tom since the latest release 2.2.2.

However, I need to work on a few issues I have with codespell before I can push such a fix.

Might as well put this in. Next time a simple and small PR against the original would be preferable. After all, if we don't do updates a few local enhancements are fine, there is already the one for "dirty".