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

Fix #2643: Introduce canonical Bazel library structure & migrate util accessibility package #2775

Merged
merged 10 commits into from
Mar 7, 2021

Conversation

BenHenning
Copy link
Member

@BenHenning BenHenning commented Feb 23, 2021

Fix #2643.

This is a replacement/continuation of #2668.

This PR does a few things:

  1. It introduces a canonical structure for laying out packages with both production & test dependencies (see https://github.com/oppia/oppia-android/pull/2668/files#r577336935) using the accessibility package under the utility module as an example (& as part of fixing Create a BUILD file for accessibility/ #2643).
  2. It introduces new top-level package groups in the root BUILD.bazel to simplify visibility management & to provide us with fine tune control (see https://docs.bazel.build/versions/master/be/functions.html#package_group).
  3. It refactors the codebase to more consistently switch between prod & test modules for the accessibility checker to ensure dependencies are properly hooked up.
  4. It does some other minor cleanups in the new package.
  5. It introduces a way to exclude migrated packages (using a glob).

One thing to note: long-term it's expected that modules will only be referenced in test dependencies & the root app binary targets. However, at the moment production modules need to be included in the main app library due to being tightly coupled with the Dagger component classes. This will continue to be the case until #1720 is finished (since then build graph inclusion of a module predicates whether it's included in the generated component).

Includes introducing new top-level package groups to simpify visibility
management. This also establishes a pattern for excluding migrated
production files.
@BenHenning
Copy link
Member Author

This replaces #2668.

@BenHenning
Copy link
Member Author

NB: I am expecting some Bazel failures, so they will need to be fixed in a follow-up commit once the run finishes.

Copy link
Contributor

@rt4914 rt4914 left a comment

Choose a reason for hiding this comment

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

Approving for files for which I am the code-owner. Thanks.

@rt4914 rt4914 removed their assignment Feb 24, 2021
Copy link
Contributor

@FareesHussain FareesHussain left a comment

Choose a reason for hiding this comment

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

@BenHenning Added some suggestions and comments, PTAL.

@@ -7,10 +7,15 @@ load("@dagger//:workspace_defs.bzl", "dagger_rules")
load("@io_bazel_rules_kotlin//kotlin:kotlin.bzl", "kt_android_library")
load("//utility:utility_test.bzl", "utility_test")

MIGRATED_PROD_FILES = glob(["src/main/java/org/oppia/android/util/android/**/*.kt"])
Copy link
Contributor

Choose a reason for hiding this comment

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

We need to exclude the files inside accessibility

I guess you need to add a kdoc here similar to app/BUILD.bazel.

Suggested change
MIGRATED_PROD_FILES = glob(["src/main/java/org/oppia/android/util/android/**/*.kt"])
MIGRATED_PROD_FILES = glob(["src/main/java/org/oppia/android/util/accessibility/**/*.kt"])

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah. I'm not sure how I missed this--thanks! Will update it locally a bit later and make sure everything's working as expected.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

Comment on lines +11 to +17
private val accessibilityManager by lazy {
context.getSystemService(Context.ACCESSIBILITY_SERVICE) as AccessibilityManager
}

override fun isScreenReaderEnabled(): Boolean {
return accessibilityManager.isEnabled
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I guess you've missed adding the Kdocs for these two functions.

Copy link
Member Author

Choose a reason for hiding this comment

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

I see just one function: isScreenReaderEnabled. Am I maybe missing something?

Also, per https://developer.android.com/kotlin/style-guide#exception_overrides KDocs aren't needed on overrides. In general, we only add them in places where they add value, and method KDocs should always be describing the API introduced by a method. This fits better in the interface or superclass as that's outlining the API implementations need to follow.

Copy link
Contributor

Choose a reason for hiding this comment

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

Got it

package_group(
name = "oppia_api_visibility",
packages = [
"//...",
Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't this similar to oppia_binary_visibility below?

if not what packages does each cover, when do we need to use oppia_api_visibility & oppia_binary_visibility

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm I tried making this clear in the documentation, but maybe it could use a bit more work. We'll generally be using API visibility unless something should only be accessible to the binary. I split them out to make the visibility groups themselves more explicit & to provide more control.

srcs = [
":AccessibilityCheckerImpl.kt",
],
visibility = ["//visibility:private"],
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need to specify this as it is private by default?

Copy link
Member Author

Choose a reason for hiding this comment

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

Nope--good point. I'll remove this when I address the other code-based changes.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

Copy link
Contributor

@FareesHussain FareesHussain left a comment

Choose a reason for hiding this comment

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

LGTM, thanks.

@FareesHussain FareesHussain removed their assignment Feb 25, 2021
Copy link
Contributor

@anandwana001 anandwana001 left a comment

Choose a reason for hiding this comment

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

Approving for files for which I am the code-owner. Thanks.

@anandwana001 anandwana001 removed their assignment Feb 25, 2021
@@ -1,4 +1,50 @@
# TODO(#1532): Rename file to 'BUILD' post-Gradle.
Copy link
Contributor

Choose a reason for hiding this comment

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

Will we be replacing all instances of //visibility:public with one of these package groups?

Copy link
Member Author

Choose a reason for hiding this comment

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

No, I don't think so. We may want to replace all instances with a package group, but the ones here are specifically corresponding to the types of libraries introduced in this PR.

kt_android_library(
name = "impl",
srcs = [
":AccessibilityCheckerImpl.kt",
Copy link
Contributor

Choose a reason for hiding this comment

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

Why use :<file_name> here

Here I've used only file name

Copy link
Member Author

Choose a reason for hiding this comment

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

Mostly auto-complete. I believe they're equivalent, but it's less code-smell to omit the ':'. Will do that in a follow-up commit.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

@@ -533,6 +532,7 @@ kt_android_library(
"//third_party:androidx_databinding_databinding-common",
"//third_party:androidx_databinding_databinding-runtime",
"//third_party:circularimageview_circular_image_view",
"//utility/src/main/java/org/oppia/android/util/accessibility",
Copy link
Contributor

Choose a reason for hiding this comment

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

I've missed this earlier.

Why are we adding the deps in app/BUILD.bazel
and why not utility/BUILD.bazel

Copy link
Member Author

Choose a reason for hiding this comment

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

Because this is where the dependency is needed. It's not used by anything in utility, and to some extent, that's expected since utility is a collection of utility libraries to be used elsewhere in the codebase.

Copy link
Contributor

Choose a reason for hiding this comment

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

Does that mean if there are any packages, which are directly used in the app module then we can directly add this in the app/BUILD.bazel?

but I think it would be better if we can pass it through utility/BUILD.bazel

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, that's how it should be. We're planning to get rid of all the top-level BUILD files--libraries should always depend as directly on the thing they need as possible. Occasionally we may introduce libraries that export parts of their implementation (which can be useful when versioning APIs), but that's something that would come after everything is modularized.

Happy to chat about this further, and I'm sure @fsharpasharp can provide some insight here, too.

@BenHenning
Copy link
Member Author

I think all of your comments are now addressed @FareesHussain. PTAL & resolve if they are satisfactorily addressed.

Copy link
Contributor

@FareesHussain FareesHussain left a comment

Choose a reason for hiding this comment

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

LGTM, thanks.

@BenHenning
Copy link
Member Author

Thanks! Looking at failures.

@BenHenning
Copy link
Member Author

BenHenning commented Mar 6, 2021

Hmm, Bazel failures seem more of the incorrect affected targets computation. Gonna see if I can repro locally & actually fix the script.

Gradle failure seems like a weird kapt flake I haven't seen before.

@BenHenning
Copy link
Member Author

Re-running tests to unblock down-stream work. Would like to try and investigate that Bazel issue, though. It's been eluding me...

@BenHenning
Copy link
Member Author

Aha, it appears the Gradle failures are real. Have some fixes to do.

@BenHenning BenHenning merged commit 76dc13d into develop Mar 7, 2021
@BenHenning BenHenning deleted the introduce-canonical-bazel-library-structure branch March 7, 2021 03:09
techjd pushed a commit to techjd/oppia-android that referenced this pull request Mar 9, 2021
… util accessibility package (oppia#2775)

* Refactor util a11y package with prod/test modules.

* Hook up new accessibility module.

Includes introducing new top-level package groups to simpify visibility
management. This also establishes a pattern for excluding migrated
production files.

* Lint fixes.

* Address reviewer comments.

* Linter fix.

* Use direct file names.

Addresses review comment.
techjd added a commit to techjd/oppia-android that referenced this pull request Mar 9, 2021
… migrate util accessibility package (oppia#2775)"

This reverts commit a89c609.
techjd added a commit to techjd/oppia-android that referenced this pull request Mar 9, 2021
… migrate util accessibility package (oppia#2775)"

This reverts commit a89c609.
techjd pushed a commit to techjd/oppia-android that referenced this pull request Mar 9, 2021
… util accessibility package (oppia#2775)

* Refactor util a11y package with prod/test modules.

* Hook up new accessibility module.

Includes introducing new top-level package groups to simpify visibility
management. This also establishes a pattern for excluding migrated
production files.

* Lint fixes.

* Address reviewer comments.

* Linter fix.

* Use direct file names.

Addresses review comment.
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.

Create a BUILD file for accessibility/
5 participants