`import('pkgconfig').generate()` generates wrong Meson introspection data

[FFY00]

Reproducible: #608

$ PYTHONPATH=../../.. python -m build -nw* Getting build dependencies for wheel...
* Getting build dependencies for wheel...
* Building wheel...
+ meson setup /home/anubis/git/mesonpy/tests/packages/python-data /home/anubis/git/mesonpy/tests/packages/python-data/.mesonpy-nc4ceydg -Dbuildtype=release -Db_ndebug=if-release -Db_vscrt=md --native-file=/home/anubis/git/mesonpy/tests/packages/python-data/.mesonpy-nc4ceydg/meson-python-native-file.ini
The Meson build system
Version: 1.4.0
Source dir: /home/anubis/git/mesonpy/tests/packages/python-data
Build dir: /home/anubis/git/mesonpy/tests/packages/python-data/.mesonpy-nc4ceydg
Build type: native build
Project name: python-data
Project version: 1.0.0
Host machine cpu family: x86_64
Host machine cpu: x86_64
Program python found: YES (/usr/bin/python)
Build targets in project: 0

python-data 1.0.0

  User defined options
    Native files: /home/anubis/git/mesonpy/tests/packages/python-data/.mesonpy-nc4ceydg/meson-python-native-file.ini
    buildtype   : release
    b_ndebug    : if-release
    b_vscrt     : md

Found ninja-1.11.1 at /usr/bin/ninja
+ /usr/bin/ninja
ninja: no work to do.

meson-python: error: Could not map installation path to an equivalent wheel directory: '/usr/lib/python3.11/site-packages/python_data/data.txt'

ERROR Backend subprocess exited when trying to invoke build_wheel

install_data here is just an example, I know I can use py.install_sources, but that is not viable in various different scenarios. In my case, I ran into it when using import('pkgconfig').generate(..., install_dir: py.get_path('purelib') / ...).

[dnicolodi]

You need to use py.get_install_dir(pure: true) not py.get_path('purelib').

[FFY00]

I am running into this issue again.

project('example', 'c', version: '1.0.0')

lib = library('example', 'lib.c', install: true)

py = import('python').find_installation()
py.install_sources('example/__init__.py', subdir: 'example')
py.install_sources('example/pkgconf/__init__.py', subdir: 'example/pkgconf')

pkg = import('pkgconfig')
pkg.generate(lib, install_dir: py.get_install_dir(pure: true) / 'example' / 'pkgconf')

It seems some targets, like configure_file work, but import('pkgconfig').generate(...) doesn't seem to.

[rgommers]

I think it's worth going through all the more advanced/niche Meson target types and checking how they land in intro-install_plan.json. I think it is going to happen again in the future that something either isn't mapped at all, or isn't mapped correctly. Right now I know of:

• import('pkgconfig').generate(...) (this example) ending up with an absolute path
• install_symlink isn't mapped at all

I bet if we look at other things that aren't normally included in wheels (e.g., jar) they won't be handled correctly by default. In most cases explicitly setting install_path should provide a reasonable workaround.

[rgommers]

So: not really a bug, more a missing feature.

[dnicolodi]

• install_symlink isn't mapped at all

Wheels cannot contain symlinks AFAIK.

[dnicolodi]

• import('pkgconfig').generate(...) (this example) ending up with an absolute path

This would be a bug in Meson.

[rgommers]

Wheels cannot contain symlinks AFAIK.

Yet:) Being heavily discussed right now. Either way, silently omitting them is probably not the ideal way of handling this now. Also intro-install_plan.json probably shouldn't be considered something that is exclusively for meson-python, so I expect it to be complete regarding all install targets.

[dnicolodi]

intro-install_plan.json cannot be complete by design: Meson allows to install the same file in multiple locations but the intro-install_plan.json is a mapping from source location to installation location, thus it cannot describe a source file being installed in multiple places. See https://github.com/mesonbuild/meson/issues/11539 and https://github.com/mesonbuild/meson/issues/12001

[rgommers]

Sure, but that doesn't quite apply to this situation. It could be as complete as possible as the metadata encoding scheme allows for.

I'd suggest to consider these Meson bugs, and once they're included in intro-install_plan.json then we have to figure out how to do something reasonable with them in mesonpython. For .pc files there's also gh-240, so those we do have to figure something out for.