Is it possible to include non-python files in a wheel generated by pants? I'm trying to include some

.yaml

files in our internal pants plugin (which we publish to our internal pypi feed) This is our

python_distribution

python_distribution(
    name="dist",
    dependencies=[
        ":version",
        ":resources",
        "//our/package",
    ],
    provides=python_artifact(
        name="our.package",
    ),
    generate_setup=False,
    repositories=[
        "@our_feed",
    ],
)

Where the files are included via

resources

target within the package. I see them as transitive filedeps

pants filedeps --transitive :dist

but not in the wheel via

pants package :dist

That should work, that's how I do it here. Can you share the rest of the BUILD file, and what you're using to define the build (setup.py, pyproject.toml)? My thought is that maybe the glob isn't working, there's a

files

target somewhere, or something you have is excluding the files (MANIFEST.in?)

I'm using

pyproject.toml

. No MANIFEST.in I narrowed this down to being related to

generate_setup=False

When I remove/flip that to True it works correctly for the wheel. I did have to disable sdist publishing though

sdist=False

and set

version="__PLACEHOLDER__",

in the

python_artifact

. We're using

vcs_version

(thats the

:version

target above) but the version is still required for some reason (and unused afaict)

I think since it works with

generate_setup=True

, Pants sees the files and is putting them into the sandbox where it runs commands to package the distribution. What build backend are you using? Are you sure there's nothing limiting the files included, and that you've set your build backend to include these files? (with setuptools that would be

[tool.setuptools.package-data]

.) Does it work if you build your distribution without Pants (maybe

python -m pip wheel --no-deps .

)?

Yeah, with

generate_setup=False

your setup.py has to copy the files into the wheel itself, like it does for sources.

generate_setup=True

will take care of it for you.

we don't have a setup.py, so that could explain it

Ah, so some setuptools default behavior is happening I suppose