Zip offers different compression algorithms and levels. For packaging,
sometimes faster compression speed is more important than size. With
`pkg_tar`, there is already the option to use a custom compressor,
there's no similar option for `pkg_zip` yet.
This PR exposes the zip `compression_level` and `compression_type`
arguments for `pkg_zip`, thus enabling the use case.
The list of compressions is the same as Python's `ZipFile`:
https://docs.python.org/3/library/zipfile.html#zipfile.ZIP_STORED
There's a new test case that verifies that the compression settings work
by comparing the compressed file sizes.
The default compression level is the same as in this recent change for
`pkg_tar` in #720
Zip offers different compression algorithms and levels. For packaging,
sometimes faster compression speed is more important than size.
With pkg_tar, there is already the option to use a custom compressor.
For pkg_zip these use case are now possible with the exposed zip
compression_level and compression_type arguments in this PR.
There's a new test case that verifies that the compression settings work by
comparing the compressed file sizes.
The default compression level is the same as recently change for pkg_tar in
* Add basic include_runfiles to pkg_files.
Show it working in a mappings tests.
Improve the mapping test to print something a little more useful.
Next step: Make the same code callable from pkg_tar and pkg_zip
* utf8 wierdness with python vesrions
* Use Label constructor for verify_archive_test macro
One of the `deps` within the `verify_archive_test` macro
depends on a label, which would be incorrectly evaluated
in a caller's BUILD file to be a non-external package.
Add a Label() call to the label to ensure it is evaluated in the
context of rules_pkg. Also add a test to ensure this can be
correctly used from another workspace.
* Merge verify_archive_test_lib into test template
Instead of exporting verify_archive_test_lib as a
public library embed it into the template for the
test itself.
* docs: add a note in pkg_tar#strip_prefix about flattening
* More gramatical description
* make the message more accurate
---------
Co-authored-by: aiuto <aiuto@google.com>
This enables the user to produce identical tarballs to fix
https://github.com/bazelbuild/rules_pkg/issues/670
Signed-off-by: Austin Schuh <austin.linux@gmail.com>
Co-authored-by: aiuto <aiuto@google.com>
* pkg_zip: improve support for long paths on Windows
This commit updates `pkg_zip` and `pkg_tar` to, when running on Windows, convert
files' input paths to extended-length paths by (1) making them absolute
and then (2) prepending with `\\?\`.
- Update to a newer rules_license
- update ci to prove that we can work with --incompatible_use_platforms_repo_for_constraints
- do not test with no_host_transition yet
Genericize package manifest system and interface
The current way that rules_pkg communicates with must packagers is using a
manifest file, which is currently a JSON data structure based on a an array of
arrays. While generally readable, it looks strange, as it was to reduce Bazel
resource usage (JSON strings in memory). Further, our Python code is directly
bound to this data structure format.
However, if we want to add more or change this, it becomes cumbersome on both
the Starlark and Python sides. This change alleviates concerns generally by:
- Converting all manifests to a JSON "object" style, improving readability.
Numerous golden tests were updated to support this.
- Replace the `collections.namedtuple`-based `ManifestEntry` object with one
that is a little more flexible and type-safe.
- Providing a function (`read_entries_from`) that converts a file-like object
into a list of `ManifestEntry`s, and replacing all JSON reading in packagers
(`tar`, `zip`, `install`) and their tests with this function.
Other convenience factors or things addressed:
- `ManifestEntry.entry_type` is now just `ManifestEntry.type`
- Bazel 6 now stringifies repository-local labels with a preceding `@`, unlike
prior versions. Adapt to this in the manifest writer.
Future changes will extend this interface to allow for custom attributes to be
passed from `pkg_files` and friends, which, among other things, will be
necessary to more generically support `pkg_rpm`.
Provides groundwork for (but doesn't resolve) #385.
Alex Eagle