wrap-direct file handling - transitively included in sdist

[WillAyd]

I am working on a multi-language project and attempting to wrap the C/C++ libraries from Python. The project layout looks something like:

c/
  meson.build
python/
  adbc_driver_manager/
    meson.build
    subprojects 

So my goal is to create targets in python/adbc_driver_manager/meson.build that depend on target(s) defined in c/meson.build

In the Python configuration, I have a dependency resolution mechanism like:

adbc_driver_manager_dep = dependency(
    'adbc-driver-manager',
    fallback: ['arrow-adbc', 'adbc_driver_manager_dep'],
    default_options: ['driver_manager=enabled'],
)

I am under the impression this will allow users who have a system install of adbc-driver-manager to link against that, and fall back to the subproject if that is not feasbile

For development purposes, I am just symlinking from the python subprojects directory to the c sources:

python/
  adbc_driver_manager/
    subprojects/
      arrow-adbc/ -- > symlinks to c/

This works well locally, but it adds wrap files to the subprojects folder that continue to point to arrow-adbc locally. For example, because arrow-adbc depends on the fmt library, a fmt.wrap file is auto-generated with the following contents:

[wrap-redirect]
filename = arrow-adbc/subprojects/fmt.wrap

When I create an sdist, wrap-redirect files like this are included. But since my symlinked subproject is not included with the sdist (and I don't believe that is desired anyway), the links in these wrap files cannot be resolved. That ends up producing an error message like:

../meson.build:18:0: ERROR: wrap-redirect /tmp/build-via-sdist-j3h00psd/adbc_driver_manager-1.6.0.dev0/subprojects/arrow-adbc/subprojects/fmt.wrap filename does not exist

When trying to build a wheel.

Is there a way to tell meson-python not to include transitive wrap files in the sdist creation, or I am perhaps going about this the wrong way?

[WillAyd]

Hmm I actually noticed this same behavior with just meson dist, so perhaps this is an upstream issue rather than something that can be solved here

[WillAyd]

See mesonbuild/meson#14520