Add rules_pkg 0.7.0

[moyamo]

No description provided.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[moyamo]

I'm not sure why the CI is failing. I copied the presubmit.yml from modules/rules_pkg/0.5.1. '-@rules_pkg//toolchains/...' was declared in the presubmit.yml, so I suspect there was a similar error on 0.5.1.

I'm not sure what I should do to fix this. I could exclude the :make_rpm target which is triggering the issue, but that feels unsatisfactory.

[fmeum]

@moyamo Could you take a look at the CI failures? Something is referencing @rules_sh_shim_exe, but the module doesn't use_repo it. Sorry, commented on the wrong PR.

[fmeum]

@moyamo The failing tests seem to require additional setup (see https://github.com/bazelbuild/rules_pkg/blob/c74ef150b11633763b127174c897205b729db832/docs/latest.md#pkg_rpm:~:text=pkg_filegroup%20and%20friends.-,pkg_rpm()%20depends%20on%20the%20existence%20of%20an%20rpmbuild%20toolchain,-.%20Many%20users%20will). Feel free to disable them.

@aiuto Would you be available to help make rules_pkg's pkg_rpm work with Bzlmod? Looks like all it would take would be a module extension calling find_system_rpmbuild(name="rules_pkg_rpmbuild").

[aiuto]

I think the extension is the way to go. People need the ability to use rules_pkg without rpm by default, and the people who want rpm need to depend on an extra thing to register the toolchain.

But... starting in bcr is the wrong way. Someone first has to make sure rules_pkg builds from modules. If you want to send me a PR that also gets CI running with and without bzlmod, that would be great.

[meteorcloudy]

Oh, I just saw this, I merged rules_pkg 0.7.0 by disabling the rpm target in #167. But would love to see the toolchain issue get fixed.

[aiuto]

Do you have a pattern available for how we are supposed to add modules that have multiple versions and some optional toolchains? For rules_pkg, we want most people to use it and only specify the module. If you want rpm, you have to also register the rpm toolchain. We'll have other optional features in the future.

Also, it's not clear what the value of the presubmit is for modules that have distinct source and distribution releases. For instance, rules_pkg has no tests available in the distribution that people use. If you want the tests, you need to import the full sources. Those have additional dependencies not recorded the bzlmod file.

[moyamo]

Thanks @meteorcloudy. I'm going to close this since #167 replaces this PR.

@aiuto

Do you have a pattern available for how we are supposed to add modules that have multiple versions and some optional toolchains? For rules_pkg, we want most people to use it and only specify the module. If you want rpm, you have to also register the rpm toolchain. We'll have other optional features in the future.

rules_nixpkgs solved the problem of optional features by using multiple MODULE.bzl files. See tweag/rules_nixpkgs#182 for more details.

[meteorcloudy]

If you want rpm, you have to also register the rpm toolchain. We'll have other optional features in the future.

We currently don't have optional dependencies support. For this case, shouldn't rules_pkg automatically register the rpm toolchain for the users?

Also, it's not clear what the value of the presubmit is for modules that have distinct source and distribution releases.

This is really a sanity check to ensure the most basic stuff work so that you don't ship broken things to user.

[fmeum]

If you want the tests, you need to import the full sources. Those have additional dependencies not recorded the bzlmod file.

That would not be an issue as the test module can specify its own set of dependencies.

[aiuto]

rpmbuild only exists on some linux versions so the auto-detection in the toolchcain only works for some users. If we had full optional toolchain support, then we could work something out, but then we have to make the rules bazel 6.x specific, and have a different version for 5.x and below. Up until now, we have been able to avoid having a rule set track for each LTS branch.