`events.csv` is not installed

[dotlambda]

When installing jaraco.abode from a GitHub archive the file jaraco/abode/helpers/events.csv is missing. Thus I get

FileNotFoundError: [Errno 2] No such file or directory: '/usr/lib/python3.10/site-packages/jaraco/abode/helpers/events.csv'

The same problem doesn't occur with the sdist on PyPI because there the file is listed in jaraco.abode.egg-info/SOURCES.txt.

[jaraco]

That's right. Alongside other projects built on jaraco/skeleton, this project uses setuptools_scm as a Setuptools "file finder", meaning it relies on the Git metadata to distinguish which files are part of the package and which are not. When installing from a GitHub archive, one loses important information about which files are tracked (essential) and which are incidental.

This project (and hundreds of others I maintain) is specifically disinterested in dual-accounting for the contents of the repository.

I do think probably your experience warrants a feature request in Setuptools_scm to have it fail when Git metadata is missing (instead of failing silently). It's conceivable that's not possible because sdists don't include that detail. Oh, indeed there's a feature request (https://github.com/pypa/setuptools_scm/issues/317).

Would it be possible instead to install the package from a git checkout (pip install git+https://github.com/jaraco/jaraco.abode@v3.2.1) or from PyPI? If you need to install offline, you could pre-build the wheel with pip wheel $github_URL.

[dotlambda]

I do think probably your experience warrants a feature request in Setuptools_scm to have it fail when Git metadata is missing (instead of failing silently).

It doesn't fail silently. In fact I have to set the environment variable SETUPTOOLS_SCM_PRETEND_VERSION because it can't determine the version using the content of .git/.

Would it be possible instead to install the package from a git checkout (pip install git+https://github.com/jaraco/jaraco.abode@v3.2.1) or from PyPI?

The former isn't because the content of .git/ isn't guaranteed to be the same from one download to the next. That's problematic when I want to use a hash to check the tarball's integrity. The latter is possible but I prefer using GitHub tarballs because that way I'm e.g. sure that I compiled all Cython extensions by hand instead of relying on ones uploaded in an sdist.

[jaraco]

I'm e.g. sure that I compiled all Cython extensions by hand

By this, do you mean you want to ensure that .pyx files are always recompiled to C at build time? That seems reasonable. It sounds like what you need is a feature in Cython that enforces this expectation. Either that or a wrapper that removes the .C files to enforce their recompilation from the .pyx in the sdist.

The former isn't [possible] because the content of .git/ isn't guaranteed to be the same from one download to the next.

There are ways to enforce content. You may be right about the .git, but you should be able to rely on Git's own hashes to ensure integrity. For example, you can associate v3.2.1 with cd9ecf8c53f289344d7385a45f76ca2e3893c23c and ensure that's the hash you build against.

If you wish to build from Git tarballs, you'll need to not only take responsibility for pretending the SCM version, but also for managing the source manifest. My suggestion - in your build routine, add a MANIFEST that lists all files in the tarball. I suspect if you do that, the include_package_data directive will once again do the right thing, and without requiring every project to dual-account for sources.

Let's figure out a solution that doesn't imply extra work and maintenance of every package.

[dotlambda]

I think I found a nice solution using MANIFEST.in: https://github.com/NixOS/nixpkgs/pull/214592