Open flode opened 10 months ago
We have a long-standing philosophy in Bazel that decoupled file paths from filesystem attributes (the rwx bits). That is a reasonable thing in the context of remote build and immutable artifact stores. It does, however, always seem strange when you build on a single machine. The end result is that rules_pkg needs to have an explicit mode for everything rather than look at the file system.
I don't want to remove the default in pkg_files, because that will surely break existing users. Nor can pkg_files look at the file system, because it is a Bazel rule, and that is not available. I'm not going to have time to think about a big design until after BazelCon, but my first thoughts are
pkg_files(name=..., srcs=..., use_filesystem_attributes=True)
would be useful.use_filesystem_attributes
capabilityThe flag is to limit the possibility of a target relying on native filesystem attributes failing when the source moves to a different environment, like a read-only network store.
The
build_tar.py
has logic to auto-detect the executable bit of the source files and also apply that in the final tar file:https://github.com/bazelbuild/rules_pkg/blob/main/pkg/private/tar/build_tar.py#L283
This logic cannot be reached however when using
pkg_tar
in conjunction withpkg_files
, as the_pkg_files_impl
doesn't allowNone
to pass through, it overwrites it with a0644
default.https://github.com/bazelbuild/rules_pkg/blob/main/pkg/mappings.bzl#L256
Is that default there on purpose? There is another default for
mode
inpkg_tar
of0555
. So the default inpkg_files
make the default ofpkg_tar
not usable.The initial problem could be solved by simply removing that default in
_pkg_files_impl
, then this code would be using the auto-detection of the executable bit:For the case where neither
pkg_files
norpkg_tar
specify a mode, the files are created with the default mode of tar (555).Would that make sense? I didn't look at the other packaging rules yet how they would be impacted.