Unable to load package for '@io_bazel_rules_kotlin//kotlin:kotlin.bzl': BUILD file not found on package path about rules_kotlin HOT 11 CLOSED

I can run the //examples/dagger project within the bazelbuild/kotlin_rules project at the same commit, but trying to load it externally seems to fail. Do we have a test in a foreign workspace anywhere, such that we can validate that the rules get loaded properly?

from rules_kotlin.

if I name the local workspace io_bazel_kotlin_rules, and symlink in the //third_party and //kotlin directories into my project, and add the maven_jar statements, I can get it to work. but as a remote repo, it doesn't.

from rules_kotlin.

I haven't tried the http file variant yet, we use the rules in our mono repo internally by just referencing the git repo.

I think you have to strip part of the repo path off when using git code archive files. See Scala rules.

from rules_kotlin.

I am hoping we can merge the google internal development efforts on the rules with the work here. We can then look at at proper release management and track the recommended versions and how to load them in the docs.

Do we have a test in a foreign workspace anywhere, such that we can validate that the rules get loaded properly?

I am sitting on some code to go into the intellij plugin that has some tests for the skylark which depends on the rules -- but this will lag behind the rules by months as the GitHub repo is a mirror.

from rules_kotlin.

I tried it with the git_repository, and it has the same outcome. There have to be differences between the internal and external versions, at least insofar as toolchains work. But this seems unrelated to any of that. Can you offer examples of how you reference it on your end? I tried what was in the skydoc and it gave the error I'm showing above.

from rules_kotlin.

Huh. You're right - the stripping bit worked like a charm (borrowing from rules_scala usage). Still, I wonder what's wrong with the git_repository flavor.

from rules_kotlin.

@cgruber on the docs front skydoc is a dead end (for me at least), I was using the latest released version as head was broken but eventually hit a brick wall with the limitations. There is no active maintainer, I created a post on Bazel discuss and some patches were merged in but head is even more broken then before.

RST like the go rules is our best bet.

(or use the tooling that native uses -- but this probably means the Kotlin rules have to become native -- which I think they should since it is such a natural fit)

from rules_kotlin.

Sorry, I guess what I meant was, I used the rules as suggested in the kotlin.bzl documentation inside that file, and I got this error.

As to kotlin rules going native, the android rules are being converted to skylark, and the plan is for the java rules to also be converted to skylark, so if there are problems that require native support, we should be pushing hard on the bazel team to expose the needed APIs so we can do what we need in skylark.

from rules_kotlin.

Hmm. I guess since the git_repository() rule is deprecated, and the http_archive() is preferred, I'll close this issue, as the issue was definitely failing to do the preliminary strip_prefix thing.

That said, I'll throw a quick note onto the readme with usage recommendations, so people can have a bit of a quick-start.

from rules_kotlin.

Github has been known to go down -- I think GitHub going down just means their web frontends.

GH uses s3 for the file storage afaik so I suppose that is the preferred production dependency -- that or using GitHub releases which also uses s3.

The rules only embedded deps (moshi and square io) so I think it's fine and the compiler is picked up from s3. So I can't see a reason for not using the repo directly s'long as we don't use the force on master ;)

from rules_kotlin.

Aah good to know about the direction of the native rules. This will mean the doc tooling used by the native rules will have to get updates.

from rules_kotlin.