-
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
Allow http_archive, git_repository and local_repository to take optional build_file/build_file_content to behave like new_* when specified #2037
Comments
Frankly I'm happier with the @kchodorow : WDYT? |
@ittaiz : Plus changing these names would mean everyone who already uses these rules would have to update their WORKSPACE files. |
Hi,
|
Sure, do you want to send an email to bazel-discuss@googlegroups.com ? |
It would make it easier to google-search to find out how to debug/fix-usage-of/apply the rules. |
@petemounce : why? you can search "bazel new_local_repository" and the first hit is the build encyclopedia (both on Google and Bing). I'm not convinced that a more WDYT? |
I already gave my opinion in general but I just want to add I think the
|
I sent this question to bazel-discuss@ |
@laszlocsomor Finding the docs is easy. Making the names more unique would make it easier to find other peoples' problems and usages in blog posts, stackoverflow, github, etc. |
As a beginner to Bazel, I remember trying to figure out the difference between new and non-new. It didn't take long to realize that it's a convention associating with a new BUILD file, therefore "bazel-ifying" a repository. FWIW: I think |
I'd be of the opinion its not worth the churn to change the name. For any of the suggested names i'd wind up googling what it means/does and and reading about it in the bazel docs. The only benefit here seems to be for looking up stack overflow questions, that doesn't seem to me personally enough to justify such a breaking change. |
I would consider this an educational issue and not a naming issue. I prefer the concise I tried to explain this in section 1.4.3: Workspace Rules that accept a BUILD file as an argument of a recent blog. |
|
https://bazel.build/versions/master/docs/be/workspace.html shows three
In all three cases, they do exactly the same thing, except the unprefixed name requires a pre-existing What if, instead, the unprefixed rules could handle both modes? The easiest way to implement that would be to add add |
@dfabulich good idea, we're going to go with your proposal. |
Indeed better than my initial suggestion :)
|
Ok closing since:
|
Just to verify by what you mean in #1- there is a flag enabling to specify
the build file already implemented?
…On Mon, 5 Dec 2016 at 12:24 Damien Martin-Guillerez < ***@***.***> wrote:
Ok closing since:
1. The new proposal is implemented,
2. We are going to deprecate new_* when we move to skylark.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2037 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABUIF1c7E6iJ4nqFROiSLf1d6zn3464Bks5rE-ZMgaJpZM4Koxiw>
.
|
Humm I thought the CL was in. Apparently not. Let's reopen this issue to track it. |
So there are skylark drop-in replacement that does that but we should do it for the native rules too. |
If we are going to make the change to the native rules, how about let's also introduce the new |
The deed is already done. All the native workspace rules support multiple urls, except for maven_jar and git_repository. |
Ah that's right. Thanks. To help with the migration, how about if we print a deprecation warning to encourage people to use |
I don't feel strongly enough about it to put a deprecation warning on it. I marked it as deprecated in the docs. I would even go so far as to remove documentation for the |
@damienmg said in 2016:
But that turned out incorrect at the time:
What about now (a year and a half later)? If the aforementioned CL exists, has it been merged? |
Damien no longer works on the team. |
All these rules are gone now, |
Following the discussion on #1952 I want to suggest renaming new_* rules to bazel_augmenting_* or decorate_with_bazel_* (so for example new_http_archive would be decorate_with_bazel_http_archive).
I know this can be a costly change but as someone who has had to lookup what new_* means several times I think it can be valuable in the long run. Fortunately Bazel isn't 1.0 yet :)
The text was updated successfully, but these errors were encountered: