Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bazel dependency rule for Prysm #6005

Closed
gnattishness opened this issue May 27, 2020 · 2 comments 路 Fixed by #6053
Closed

Bazel dependency rule for Prysm #6005

gnattishness opened this issue May 27, 2020 · 2 comments 路 Fixed by #6053
Assignees
Labels
Enhancement

Comments

@gnattishness
Copy link

@gnattishness gnattishness commented May 27, 2020

馃殌 Feature Request

Description

Implement a solution for external bazel projects to easily depend on Prysm.

Currently, this requires the external developer to copy the majority of Prysm's WORKSPACE into their own and update it whenever Prysm's WORKSPACE changes.

(This was originally discussed with @prestonvanloon out-of-band, but I've made the issue to track it)

Describe the solution you'd like

The conventional solution would be for Prysm to define a prysm_deps() bazel rule in a deps.bzl file, which specifies all relevant dependencies for building Prysm, and would be called by Prysm's own WORKSPACE.

External projects can then, similarly, load the deps.bzl and call this prysm_deps() rule in their own WORKSPACE.

Below is an example of a fairly mature implementation of a similar setup:
https://github.com/google/tink/blob/8bdaed4f41edc01821be9b089123410be0b57a6c/tink_base_deps.bzl
With example usage as a depending project: https://github.com/google/tink/blob/8bdaed4f41edc01821be9b089123410be0b57a6c/examples/cc/WORKSPACE

Note the if not native.existing_rule("rule_name") notation, which stops the build from breaking if there is another/existing rule specifying the same dependency.
This allows the developer to choose a suitable version when more than 1 library requires the same dependency.

Describe alternatives you've considered

Current workaround is mentioned in the initial description.

@prestonvanloon prestonvanloon self-assigned this May 27, 2020
@prestonvanloon prestonvanloon added Enhancement Refactor labels May 27, 2020
@prestonvanloon
Copy link
Member

@prestonvanloon prestonvanloon commented May 27, 2020

I鈥檒l have this done by EOW. Thanks for filing an issue to track it!

@prestonvanloon
Copy link
Member

@prestonvanloon prestonvanloon commented May 29, 2020

This is in progress, should have a PR ready soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants