[Hatchling] Interpolate variable version in section tool.hatch.build.targets.wheel.force-include somehow?

[hartwork]

Hello Hatch, 👋

thanks for sharing this PEP 517 backend and adding custom hooks to it! 🙏

In context of a non-trivial conversion towards pyproject.toml with Hatchling I've been trying to make a wheel install man pages to where Linux distros would expect them, and technically it seems I succeeded judging by the wheel content…

# unzip -l dist/latex_rubber-1.6.5-py3-none-any.whl | grep man | awk '{print $NF}' | sort
latex_rubber-1.6.5.data/data/share/man/fr/man1/rubber.1
latex_rubber-1.6.5.data/data/share/man/fr/man1/rubber-info.1
latex_rubber-1.6.5.data/data/share/man/fr/man1/rubber-pipe.1
latex_rubber-1.6.5.data/data/share/man/man1/rubber.1
latex_rubber-1.6.5.data/data/share/man/man1/rubber-info.1
latex_rubber-1.6.5.data/data/share/man/man1/rubber-pipe.1

…but the way I got there makes me keep wondering:

• if and why magic path <distribution>-<version>.data/data/ is as underdocumented or too-hard-to-find in the Hatchling world (and elsewhere?) as it seems to me,
• if there is a way to interpolate variable version in pyproject.toml section tool.hatch.build.targets.wheel.force-include or if a custom build hook is the only option,
• if it has to be this hard or if there are better ways to ship and install man pages with regard to Hatchling.

If this is too much in one ticket, I can split things up, I just wasn't sure how and if I should.

Would be great to understand what I'm missing, thanks in advance for you reply! 🙏

Best, Sebastian

CC @Flowdalic @hannob

[ofek]

Hey there!

• It's not very documented but is something Python installers are supposed to support and that won't ever change
• I don't quite understand the ask, can you explain what you mean?
• Do you mean like this? https://github.com/jupyterlab/jupyterlab/blob/8819549495cd11470b4db7464d1d59c53cfce787/pyproject.toml#L138

[hartwork]

Hi @ofek, thanks a lot for your reply and help!

• Do you mean like this? https://github.com/jupyterlab/jupyterlab/blob/8819549495cd11470b4db7464d1d59c53cfce787/pyproject.toml#L138

Thanks for that pointer! I first copied from there, expected to see failure, and then found that the feature is indeed working and just what I was looking for — awesome! — , but ignoring errors silently (which seems like a dangerous default, e.g. because every typo leads to a missing file in the archive).

I have created upstream pull request https://gitlab.com/latex-rubber/rubber/-/merge_requests/36/diffs now applying your idea.

• It's [..] something Python installers are supposed to support and that won't ever change

That's good to know.

• I don't quite understand the ask, can you explain what you mean?

With the situation changed now, I think it would be great if

• tool.hatch.build.targets.wheel.shared-data could be made unforgiving of missing files, say by adding a boolean switch that defaults to current forgiving behavior, and then make it strict when there is a chance for a breaking change? Does a switch like that exist already? I'm quite worried of the new file list breaking without someone noticing. We can build CI specifically for it, but making build error out on missing files would be a clear favorite.
• https://hatch.pypa.io/dev/plugins/builder/wheel/#options could maybe mention e.g. man pages or Bash completion files for examples of use of shared-data (maybe even a more extensive list) and/or would somehow be easier to find: if I did see it before, it was too abstract to recognize for an answer. I must say it's not easy to find things in Hatchling docs as a user unless you know every well already what you are looking for. Maybe because it feels like a reference but would have needed an FAQ, a tutorial, an "how to X" list. I checked the existing ones, but from a quick look none seems to cover man page installation or something close, and also there is two competing menus — a vertical and a horizontal one — and mostly very abstract titles like Managing environments (and I don't know environments yet). I don't mean to bash the documentation — it's great there is some — but given that non-trivial Python packaging seems to be a mystery to most people I talk to, I believe these docs may need a practical UX testing session.

What do you think?

CC @Flowdalic @hannob