Remove build hacks

[flying-sheep]

Also switches from flit-core to hatchling, but at this point, that’s just a backend change.

It uses setuptools-scm (via the hatch-vcs plugin) as a build hook, so the version will ship in a generated _version.py file.

[codecov]

Codecov Report

Merging #1001 (287c981) into main (d346beb) will decrease coverage by 0.03%.
The diff coverage is 64.28%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1001      +/-   ##
==========================================
- Coverage   84.11%   84.08%   -0.03%     
==========================================
  Files          34       33       -1     
  Lines        4727     4707      -20     
==========================================
- Hits         3976     3958      -18     
+ Misses        751      749       -2     

Impacted Files	Coverage Δ
anndata/__init__.py	64.28% <64.28%> (-35.72%)	⬇️

[Koncopd]

Hi.
What is this hatch? Is it something like poetry?
I would really prefer to keep flit as it is pretty mininal.

[flying-sheep]

Hatchling is the build backend we use in the scverse-cookiecutter template.

Compared to flit-core, it’s less opinionated (doesn’t derive version metadata from <pkg>.__version__, doesn’t derive the description from the docstring – a feature we haven’t been using) and supports plugins (which this PR uses by replacing the whole hacky _metadata.py file with the plugin-generated _version.py.

Its maintainer is also quicker with fixes and incorporation of new packaging standards. But as said: the main reason for this is that the _metadata.py file has accumulated a bunch of hacks to accomodate flit, and this makes things much simpler.

[ivirshup]

I'm fine with going from flit to hatch, less sure on hatch-vcs.

Does hatch-vcs add commit info, or is it all tag based? My recollection is that it will be wrong most of the time for development builds/ editable installs.

Is hatch + setuptools-scm an option?

See also: https://github.com/maresb/hatch-vcs-footgun-example

[flying-sheep]

Is hatch + setuptools-scm an option?

See initial comment:

[This PR] uses setuptools-scm (via the hatch-vcs plugin) as a build hook, so the version will ship in a generated _version.py file.

[ivirshup]

I recall this throwing errors if I didn't specify the content-type. Was that flit specific?

[flying-sheep]

not for many years: pypa/flit#169

[ivirshup]

Pretty sure I was running into this more recently than that. But I believe twine check was the one complaining, so it's fine as long as the build check is passing.

[ivirshup]

It's more that I don't see how setuptools-scm is being used from the changes.

How does this not have the behavior described here:

Editable installs

The version file is only updated upon install or build. Thus the version number in an editable install (Hatch's dev mode) will be incorrect if the version changes and the project is not rebuilt. An unsupported workaround for keeping the version number up-to-date can be found at hatch-vcs-footgun-example.

[flying-sheep]

To summarize our in-person discussion:

There’s no way to have the version in the package metadata automatically up-to-date. It can only be updated when (dev-)installing your package anew. There’s a discussion about adding dynamic version metadata here

The __version__ convention is of dubious value (packages usually look things up from package metadata using importlib.metadata), but of course it can be calculated using runtime code. That’s explained and demonstrated here.

“Ideally”, we’d run that code in dev mode, and a simple from ._version import __version__ in an installed package, but there seems to be no easy way to use hatch-vcs to generate different code based on the dev-ness of of the install.

[ivirshup]

Review

Could we add a step to the build check where we check that the built package imports and has a __version__?

One other point from discussion

We'd also discussed if we could strip out all the version finding logic and just hardcode the version for releases.

[ivirshup]

Pretty sure I was running into this more recently than that. But I believe twine check was the one complaining, so it's fine as long as the build check is passing.