-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
skylark new_git_repository rules react different than native rule with build_file #2997
Comments
I think it should be consistent between both native & skylark rules if you do:
...but you are correct, these should be consistent. Edited to add: but I'd recommend not using bind() anyway, so if that's an option, prefer that. |
Why? In the end it seemed to me that the //external package is the most logical place for external dependencies to reside in. Anyways, yes, specifying the full path instead of just the file name seems to work. |
I implemented it, but in retrospect I think it was a mistake. Labels in Bazel are nice in that you know where to find everything: //x/y is in the directory project/x/y. @foo//x/y is under /foo/x/y. //external breaks this: you have no idea where something defined by external was defined. This will be especially bad once #1943 is implemented and you have multiple WORKSPACE files contributing definitions. Feel free to chime in on #1952, which is a long discussion about possibly removing bind. |
I assumed that bind() is a nice way to keep external dependencies abstract (e.g. if everyone depends on //external:foo it is easier to switch foo 1.0.0 for 1.0.1 without having to rewrite every dependency that uses foo). Beyond that I don't have many arguments for/against bind(), I agree that it looks kinda weird with that "virtual" //external namespace, though I also find it nice to have a way to explicitly state that something is loaded from the outside. This is more me trying out to get some builds going rather than putting my foot down in a "you'll take bind() from my cold dead hands" kinda way. It would be nice though to get a few best practices going, but that's anyways also in the interest of the BUILD file repo task force. :-) |
:) We actually do have a start of a "Best practices" doc: https://bazel.build/versions/master/docs/best-practices.html#repository-rules. Generally we recommend using names like |
Please provide the following information. The more we know about your system and use case, the more easily and likely we can help.
Description of the problem / feature request / question:
When playing around with new_git_repository and after reading the hint that I should use the skylark ruleset from "@bazel_tools//tools/build_defs/repo:git.bzl" instead of the native "new_git_repository()" I ran into the issue that the skylark rules apparently seem to work differently after a bind command (see example).
While the native rule (only) accepts files in the root folder of the workspace as build_file, the skylark ruleset seems to look in a subfolder.
I would expect the skylark rule to be a drop-in replacement of the native rule, or at the very least that the expected build_file location is documented for that rule.
If possible, provide a minimal example to reproduce the problem:
now with the skylark rule uncommented:
Apparently the "bind()" rule later on seems strong enough to cause skylark to expect the BUILD file to be in a sub-folder named "external", which doesn't exist.
(The choice of the boost align library is unrelated to this, it is just something that I want to write some rules for)
Environment info
Operating System:
Manjaro Linux
Bazel version (output of
bazel info release
):release 0.4.5- (@non-git)
If
bazel info release
returns "development version" or "(@non-git)", please tell us what source tree you compiled Bazel from; git commit hash is appreciated (git rev-parse HEAD
):https://www.archlinux.org/packages/community/x86_64/bazel/
Have you found anything relevant by searching the web?
I wish...
The text was updated successfully, but these errors were encountered: