Closed fnichol closed 1 year ago
Sorry about the breakage.
I think the correct behavior would be to not emit a licenses
attribute at all in this mode.
licenses
is not meaningful to any code in the prelude as far as I know. The only uses are by external tools, which are able to do things like:
$ buck2 uquery 'kind("rust_library", //...)' --output-attribute license
{
"root//third-party:owo-colors-3.5.0": {
"licenses": [
"root//third-party/vendor/owo-colors-3.5.0/LICENSE"
]
},
...
}
In the short term, you can unblock yourself without reindeer changes by adding a macro (or maybe you already have one).
# third-party/defs.bzl
def rust_library(**kwargs):
kwargs.pop("licenses", None)
native.rust_library(**kwargs)
# reindeer.toml
[buck]
buckfile_imports = """
load("//third_party/defs.bzl", "rust_library")
"""
(Reindeer will still put the bad paths into your generated targets, but it won't break your build anymore.)
Confirmed that's working great, thank you! 🎉
As mentioned in #11:
Funny enough, this is precisely the issue I was running into this afternoon, and with the
owo-colors
LICENSE
location, leading to abuck2 targets //...
error like:I was operating under the assumption that the relative path to
LICENSE
was outside the Buck2 package. Ideally, what would be a reasonable value for thethird_party_rust_library
rule'slicenses
argument? I'm working backwards in Reindeer's code to understand, so forgive a newcomer 😄