Update rules_* bazel dependencies

flyingsilverfin commented 12 months ago

What is the goal of this PR?

We follow the upgrade of bazel to 6.3.0 to upgrade our dependencies to the latest versions, in particular of rules_python, rules_pkg, and rules_jvm_external. Following these upgrades, we can also remove some hacks around documentation generation.

What are the changes implemented in this PR?

Upgrade rules_python, rules_pkg, rules_jvm_external, as well as stardoc and skylib
Remove hacks used to generate our stardoc-based README
Replace usage of pip_install with pip_parse followed by an install step
Fix an issue in npm, which can have permission errors when writing to the users's global cache
Delete patch files that are unused after upgrades

We also have to allow assemble_maven to proceed when there is no pom or runtime_output_jar produced. This appears to produce no errors, but is related to discussions in https://github.com/vaticle/bazel-distribution/issues/335 . The requirement to relax assemble_maven comes from trying to build https://github.com/flyingsilverfin/typedb-protocol/commit/546028d9e26ba082204a5c19df83510e5d4f5abd for the //grpc/java:assemble-maven target, which fails without the relaxation of the assemble_maven rule.

vaticle-bot commented 12 months ago

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

Trivial Change

[ ] This change is trivial and does not require a code or architecture review.

Code

[ ] Packages, classes, and methods have a single domain of responsibility.
[ ] Packages, classes, and methods are grouped into cohesive and consistent domain model.
[ ] The code is canonical and the minimum required to achieve the goal.
[ ] Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
[ ] Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
[ ] The code is algorithmically efficient and scalable for the whole application.

Architecture

[ ] Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
[ ] Any required build and release automations are updated and/or implemented.
[ ] Any new components follows a consistent style with respect to the pre-existing codebase.
[ ] The architecture intuitively reflects the application domain, and is easy to understand.
[ ] The architecture has a well-defined hierarchy of encapsulated components.
[ ] The architecture is extensible and scalable.

flyingsilverfin commented 11 months ago

We are going to park this PR until we want to revisit upgrading the Bazel dependencies. This work can continue after the FFI-based clients are completed.

flyingsilverfin commented 10 months ago

Closing since incorporated in https://github.com/vaticle/bazel-distribution/pull/382

vaticle / bazel-distribution