BUILD File with Extension

[John Cater]

I'm working on issue #552 (https://github.com/bazelbuild/bazel/issues/552), "Allow customizing "BUILD" as a package-specification file". After some testing and profiling, I have the approach in hand, except for one problem... what is the new filename?

The basic approach will be to update PackageLookupFunction to first check for a file with the new name, then look for a file named "BUILD" for those using that. Only looking for one filename, or having a per-workspace customization, would break the case of referring to external repositories (what if they are using a different build file name than you?), so the two-file solution is the best.

Options, ranked from my favorite to my least favorite:

1. BUILD.bzl

  Pros: Simple, unambiguous. We already are naming files with the .bzl extension, so it's well-known.

  Con: Someone might try and load() a BUILD.bzl file, so we'd need a check to prevent that. Tools that perform file analysis or syntax highlighting will need to be aware of the rule to distinguish them.

2. BUILD.bazel

  Pros: unambiguous. Different from the .bzl we use to denote loadable extensions.

  Con: Longer to type. Still need to update tools and syntax highlighters.

3. Buildfile

  Pros: Similar to Makefile, Gemfile, etc

  Cons: Different from the existing BUILD, so possibly confusing.

Are there any pros or cons I have missed? What do people think?

Thanks,

John C

[Kristina Chodorow]

For 1), the flip side of the con you mentioned is that someone could have a build.bzl Skylark extension, which would be fine on Linux but be equivalent to BUILD.bzl on OS X.

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/c29b6f1f-fc17-4de2-9490-e3f14892727a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Cater]

That's true, we'd want to disallow load() for all files that looks like build.bzl case-insensitively.

[Erik Abair]

I have a strong preference for #2 (or anything that's neither #1 or #3).

I'm strongly opposed to #1 as OS X does not have a mechanism to differentiate between file extensions in a contextual way. .bzl files will all be considered as one group so having them sometimes be Skylark and sometimes be BUILD files would be bad. Also having to modify Bazel such that it disallows build.bzl is going to feel like a strange limitation, particularly for people who are not working on OS X or with a case (preserving but) insensitive file system.

For #3 I think you've captured the primary con - having a total departure from BUILD is likely to be an issue for people.

I really like #2, but it's already being used by the Bazel team in the tree to denote files which should be transformed into BUILD files when exported for OSS consumption. I prefer it to the point that I'd argue in favor of changing the way Bazel is packaged, but it's easy for me to argue for work that somebody else would end up having to do :)

I suspect we're all on the same page, but I don't think the "longer to type" con is a significant one as, from a practical standpoint, you're more likely to edit the file than create the file, which means you're probably typing "BU\tba\t" which is no worse than "BU\tbz\t".

[Erik Abair]

and it's _awesome_ that you're taking this on, BTW :)

[John Cater]

I didn't realize that was the case for OS X. Given that, I agree that BUILD.bazel is the best choice (I've already looked into the work needed to handle the existing .bazel files).

[Tom Lundell]

Side note: Our tooling (IntelliJ BUILD file support) will be unhappy with the BUILD + BUILD.bazel files of the blaze codebase once we turn that on. The parallel BUILD files will (naturally) conflict for things like definitions.

Not something that should determine the outcome of this discussion, but the blaze team might have to rename all BUILD.bazel files if they want BUILD file integration while editing blaze source code.

[David Maclachlan]

+1

[Jon Brandvein]

To add some pros for #1:

  - Having the same extension for build files and Skylark files mirrors how Python uses .py for both ordinary source files and for the special __init__.py file. There's an analogy between how __init__.py indicates that a directory is a Python package, and BUILD[.*] indicates that a directory is a Bazel package.

  - To the extent that the build language and Skylark are intended to be "the same" language, just with different levels of restriction, they should have the same extension. It's not clear to me why we want the OS to distinguish between them.

[Erik Abair]

A not-entirely-strawman argument to differentiate between the two is to open up interesting Finder integrations. e.g., double clicking on a BUILD file could kick off a build of the default target or it could pop open a new Tulsi project prepopulated with the relevant package. 

The Tulsi usecase is what triggered my interest in this issue originally, though any extension will be a big improvement over the current no-extension case.