I think that most of the rules that Bazel comes with now did not exist when Heron was under its core development cycles. Now when it comes to upgrading Bazel I would ask the dev@ for feedback if you have to make a decision on what is the best way to go, offering your perspective as well. If you feel that it is simpler to remove some custom rule implementations then I would make your case write a proposal and send it off to dev@ to get feedback and support on the issue. I think it's safe to say we are all looking for a simpler way to manage the Bazel build rules within the Heron code base and we would be happy to get suggestions or feedback on any of our current Bazel usage/implementation today.
- Josh On Fri, Jan 17, 2020 at 12:19 PM Ning Wang <[email protected]> wrote: > My feeling is that, Bazel moves fast. When Heron was started, Bazel was > still young (4+ years ago) and many tasks have to be done via custom rules. > And when upgrading Bazel, it is often not backward compatible ..... so the > effort is to fix the build, not clean it up. > > However I was not in the team when the project started. Karthik, Sanjeev, > Maosong, Neng, Huijun should have more information. > > On Fri, Jan 17, 2020 at 6:37 AM Nicholas Nezis <[email protected]> > wrote: > > > Can I start a thread for a quick discussion about Bazel? I apologize if > > this is a silly question. I'm new to Bazel. > > > > I'm curious why there are so many custom rules defined in the Heron repo > > (tools/rules). I see Bazel provided rules that we could leverage for > things > > like JarJar and Javadoc and Python, etc. Are there specific reasons why > > there is custom logic in the Heron repo? Or was it maybe historical > because > > the Bazel provided resources didn't exist at the time? I was looking at > > upgrading our use of Bazel to 1.X. Upgrading our custom logic seem harder > > than upgrading a version of a Bazel provided rules dependency. > > > > Thanks, > > Nick > > >
