bazelbuild
tweak(whl_library): capture arbitrary files as data
This fixes wheels like ruff which want to emplace bin/ and other dirs used as library data.
Thanks for the PR @arrdem, could you please fix the tests and add a CHANGELOG item so that we can merge it? This looks like a really useful feature.
Wilco. Work's a bit crazy atm just wanted to get this patch in the upstream pipe before I forgot about it since it was trivial.
Hrm. Reading through https://peps.python.org/pep-0491/#file-contents, I'm wondering if this actually makes sense. It feels like while it may well make sense to have a :data filegroup, we probably want to handle at lest data, scripts and include separately. While for my purposes it's good enough to just have a build rule that encloses the ruff binary it would be better if we could identify scripts as part of unpacking the wheel and make them usable as entrypoint rules rather than just files.
On the same note whether the data should be a dependency of the library seems arguable.
Looking at https://peps.python.org/pep-0491/#install-paths I am wondering if the right way to fix this would be to add the extra filegroup targets for each item listed in the UNIX install scheme.
That said, we may want to include all of those filegroups into the py_library so that the library can work correctly - Python can do whatever and assume that the files are installed in site-packages so I am wondering if adding the filegroups on the other hand would be not effective at all.
That said having the filegroups exposed would make the numpy header inclusion easier and users would not need to use whl_filegroup in their build graph to just extract a few files.
Missclick.
That makes sense to me. The main other thing I want to do is to teach the wheel installer to identify scripts/binaries already in the bin/ tree and add entrypoint metdata for them automagically. Will try to revisit this.
Thanks! Is it so that you could later use the py_console_script_binary to use those scripts?