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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move public Starlark API to defs.bzl #53

Closed
wants to merge 1 commit into from
Closed

Conversation

artem-zinnatullin
Copy link
Contributor

@artem-zinnatullin artem-zinnatullin commented Jan 14, 2020

Attempt to put everything back in a single public api file to improve user experience, I'm still trying to remember exactly why did we do macros in separate files #36

I remember we were trying to break some circular dependencies and allow user to customize certain things, however so far this PR passes our CI setup here and works in Lyft project

@artem-zinnatullin artem-zinnatullin changed the title WIP: Move public Starlark API to defs.bzl Move public Starlark API to defs.bzl Jan 14, 2020
Move dependencies to WORKSPACE

Fix buildifier

subheaders in comments

# Runtime

## Dependencies

load("//detekt:dependencies.bzl", "rules_detekt_dependencies")
### Java
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh. Yeah, it will work (I think) but rule users will be forced to declare all dependencies on their own. This is easy to reproduce with creating a completely separate workspace and attempting to use rules_detekt there. It works there of course and will work at the Lyft repo since all dependencies are declared there (I can only guess as a legal Lyft employee). However, at least rules_proto is far less common than rules_java.

In fact, the whole motivation behind #36 was to provide a way to use rules_detekt without declaring everything that is needed internally by the rule itself.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this is a bit lost on me as my understanding of included WORKSPACE is that it'll inflate their dependencies even if I don't have them in my WORKSPACE, I'll need to play with it a bit more…

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sadly when you depend on an external repo, Bazel doesn't parse its WORKSPACE at all. So with those changes, like @arturdryomov mentioned, clients would have to replicate the set of dependencies.

The rules_kotlin repo is moving away from this problem (partly, that's not the intent afaik, just a side effect) by shipping a prebuilt worker (bazelbuild/rules_kotlin#271), maybe a similar solution could help here?

@artem-zinnatullin
Copy link
Contributor Author

Closing then :)

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

Successfully merging this pull request may close these issues.

3 participants