Add some comments to tests/WORKSPACE

[ghost]

Hi there,

I am looking at this project and it looks very interesting. Thank you for the effort. It also seems in many respects more complete than [Bazelbuild scala].

While trying to learn how to use the rules, I noticed the tests directory contains WORKSPACE and BUILD files, which also seem like very good places to get started given the lack of more complete user documentation.

Would you consider commenting them with short explanations as to what the individual steps are for? Something along the lines of "This is required for so-and-so", "This does Y because it's considered best practice" and "This does so-and-so but it's only here for the benefit of these tests"? It seems not all the functionality used has documentation yet.

Alternatively, could you add an example "best-practice" project with a similar level of comments, perhaps including two scala and JDK versions?

Thank you,

Tom

[borkaehw]

commenting them with short explanations as to what the individual steps are for

Sounds like an interesting idea. Do you only refer to the tests/WORKSPACE file? I believe most of the valuable logic is in rules/, or *.bzl, have you tried to take a look and also found them lacking comments?

add an example "best-practice" project

It could be easy and also hard, it depends on how complex is the project. Is it good enough to be able to build a "hello world" project?

[ghost]

Hello,

Thank you for your reply.

I mostly meant just the WORKSPACE file, yes.

Parts of it I recognize based on the documentation I've read but not all steps are completely clear to me. So having a minimal, commented best-practice (perhaps with scalacheck, strict deps etc) template would be super useful.

Some things which I don't fully understand right now:

• the recommended practice of how to build the same libraries/binaries with different scala versions

• is there support/recommendations for building with different JDK versions (similar to e.g. your tests/BUILD), and how? (I've looked at the Bazel Java platform documentation but I think the code has not been merged yet on Github.

• external deps: I've seen it mentioned that the project uses 'rules_jvm_external' and seen the calls in your WORKSPACE to 'annex_scalafmt_pinned_maven_install' but it's not clear to me from the tests/WORKSPACE what the recommend practice is for external dependencies, and how to pin them correctly, since these calls are not documented (AFAICS) - so I'm not sure if they are part of the public API. Should I use the API provided by these rules? Do the rules understand and depend on the correct artifacts based on the selected Scala version? Etc.

As as aside, I would be happy to take a simple example and extend it or improve the docs for it as a way to contribute back. I can definitely cobble something basic together from my current understanding but when it comes to some of the questions above, I am afraid that as a fairly new bazelite I am a bit out of my depth.

As a final question - it seems the APIs of this project are very similar to the aforementioned bazelbuild/rules_scala. Are these two projects related in some way?

Thank you,

Tom

[SrodriguezO]

Hey Tom,
Sorry for the delayed response. Things have been very busy lately. I think adding a sample project and/or thoroughly commenting the tests workspace would be wonderful. We don't currently have the bandwidth to undertake these tasks, unfortunately.

I'll do my best to answer your specific questions though:

• You can specify which scala compiler you wish you use for a target via the scala attribute. More info here.

• To specify a different JDK version, we download the jdk we're interested in (A), use it to create a java_runtime (B), and then specify this as the --javabase in our .bazelrc (C). It's not really part of these rules, but probably something we should document more clearly given that Scala 2.11 requires it.

• For external dependencies, we do recommend using rules_jvm_external. I wouldn't suggest using tests/WORKSPACE as an example for external deps, since afaict there's quite a bit of legacy stuff there. The rules_jmv_external docs are fairly thorough though.

Regarding your final question, bazelbuild/rules_scala and higherkindness/rules_scala do share many similarities. higherkindness/rules_scala was born largely out of a need for more customizability and for incremental Zinc compilation support. The former of these has been addressed, and we're (slowly) working on the latter. The goal is to eventually rejoin the main rules_scala effort, once we've ensured feature parity and a simple migration pathway. In the meantime, we'll continue supporting higherkindness/rules_scala.

[ghost]

Thank you for the the thorough response.

I have my own deadlines this week but let me see if I can put something together.

Again, I appreciate you (both) taking the time.

[pauldraper]

bazelbuild/rules_scala is plagued by a number of compatibility and functionality issues that are not fixable without a large rewrite.

The used to be a comparison to bazelbuild/rules_scala but it was removed in #232 to be nicer.

You can see the old version here (though some things are likely out-of-date).

[ghost]

A quick follow up: Due some recent changes, this (nor Scala!) are on my radar anymore. I wanted to circle back and not let the issue in an unresolved state. I am happy to close it, unless you have a different preference?

Thank you again for your thoughts/feedback above.