Closed gmendonca closed 4 years ago
take a look at:
https://github.com/bazelbuild/rules_scala/issues/445 https://github.com/bazelbuild/rules_scala/issues/366
There are subtleties with some macro set ups and open issues not resolved.
To your point: yes, many external libraries could be non-macro imported, which would run ijar on them and could result in better cache hits, but I'm skeptical of that. ijar removes the code, which can only increase cache hit rates. But when you bump a version of a jar, it is very rare that the ijar would wind up being exactly the same after that. Furthermore, bumping external dependencies is pretty rare.
So, my bias would be to simplicity here.
That said, I'm open to adding optional options if we can make it clear what problem we are solving.
Thanks for taking the time to open an issue.
I'm closing this as I agree with you design choice. And, in the above case, importing like this does solves the issue:
com.beachape:
enumeratum-macros:
lang: scala
version: "1.5.10"
enumeratum:
exports:
- "com.beachape:enumeratum-macros"
lang: scala
version: "1.5.13"
Yo, I'm trying to make https://github.com/lloydmeta/enumeratum to work with bazel-deps:
And when trying to build, I'm getting:
As per my understanding we're defaulting
scala_import
for any scala dependency, but there are situations where using https://github.com/bazelbuild/rules_scala/blob/master/docs/scala_macro_library.md or https://github.com/bazelbuild/rules_scala/blob/master/docs/scala_library.md would have a better fit. If my assumptions are correct, we could support this through an optionkind
: