Bazel: Change where bazelrcs are read from, and make it easier to control which ones are read.

[drigz]

Description of the feature request:

Check for bazel/bazel.rc in addition to tools/bazel.rc. This could also be done for tools/bazel and any other special files that can be in tools/.

Feature requests: what underlying problem are you trying to solve with this feature?

Projects that support multiple build systems prefer to keep the files separated as far as possible. However, Bazel forces you to add a tools/ top-level directory to use certain functionality. See this comment from googlecartographer/cartographer#834 which prompted this issue.

The bazel/ subdirectory is fairly common for builds that support multiple systems, eg gRPC, glog, Google Cartographer, Ceres Solver. Exceptions (ie projects with no bazel/ subdir) include TensorFlow and gRPC Java, although IMHO the latter is good example of where it would help clean things up.

What operating system are you running Bazel on?

Ubuntu 14.04

What's the output of bazel info release?

release 0.9.0

[ixdy]

Kubernetes is another project which would benefit from something like this. We currently have a .bazelrc in the repo root, which is overriding users' $HOME/.bazelrc, so we should fix this.

We don't have a tools/ directory (though we do have a build/), and I'm not super excited about creating tools/ solely for one file.

[helenalt]

@jhfield @lberki please help prioritize an owner as this affects multiple users

[lberki]

(assigning to @cvcal since she worked with option parsing more recently than both @lfpino and @iirina)

I think this is a good idea; tools/bazel.rc is mostly a heritage from our internal repository. I think using $WORKSPACE/bazel.rc is more reasonable than tools. I'm not thrilled about $WORKSPACE/bazel/bazel.rc, though -- why create a directory just for one file?

Migration will also need to be given some thought; we could either just change in a Bazel release since projects can simply symlink one location to the other to support building with Bazels both before and after the flag flip or have a release that supports both, then remove the old location in the subsequent release. I think the first plan is simpler and the migration costs are not too onerous.

WDY'allT?

[iirina]

I'm not thrilled about $WORKSPACE/bazel/bazel.rc, though -- why create a directory just for one file?

Seems like the reasoning is that a lot of projects already have the bazel directory.

Is it possible to specify in the WORKSPACE file the location of the bazel.rc file? So that every project could put bazel.rc wherever they want.

[lberki]

Specifying it in the WORKSPACE file doesn't work; the rcfile is parsed from the launcher, which doesn't speak Skylark.

[drigz]

I'm not thrilled about $WORKSPACE/bazel/bazel.rc, though -- why create a directory just for one file?

Seems like the reasoning is that a lot of projects already have the bazel directory.

Yes, and specifically that bazel/ is desirable name for projects that support other build systems. Also, $WORKSPACE/bazel.rc and $WORKSPACE/.bazelrc would be (even more) easily confused.

[cvcal]

I actually was just talking to Luis and Klaus about this (context b/70843852 & b/36168162, for Bazel team members).
Bazel currently loads 3 master bazelrcs, or none, if --nomaster_bazelrc is passed. I find this horrible, there is no way for users to pick which of these files should be loaded, no way for one of these to be ignored while others kept. I'd rather we not add a 4th location from which we look for a master rc without improving this with a more granular switch.

On the question of which files should be in that list, Klaus had written a proposal for what the bazelrc world should look like a few years ago, hidden in https://www.bazel.build/designs/2016/06/21/environment.html. It doesn't contain exactly this suggestion, but might be a good starting point. I think it would be great if we can work something that is similar to the standards in other open source projects, but I don't know much about those standards so I can't speak to the WORKSPACE/bazel directory in particular.

[cvcal]

The current workaround: If this is the best place for you to keep workspace-wide options, the rc file next to the bazel binary could import %workspace%/bazel/bazel.rc.
I realize this isn't a solution, since this request is to change the standard, but I thought I should mention that.

[drigz]

Excellent points, Chloe. After collecting the info below, I have realized it's even more complicated than I thought. I've listed in decreasing precedence and only summarized the unix behaviour; some of the source links describe behaviour on other platforms. (any mistakes my own)

maven (source)

• specified with --settings
• A user’s install: ${user.home}/.m2/settings.xml
• The Maven install: ${maven.home}/conf/settings.xml

(note: someone patched the maven script to support per-project settings)

gradle (sources 1 and 2)

• $WORKSPACE/settings.gradle (a Groovy script)
• $WORKSPACE/gradle.properties (a key-value file)
• ~/.gradle/gradle.properties (a key-value file)

npm (source)

• per-project config file (/path/to/my/project/.npmrc)
• per-user config file (~/.npmrc)
• global config file ($PREFIX/etc/npmrc)
• npm builtin config file (/path/to/npm/npmrc)

pip (source)

• inside a virtualenv: $VIRTUAL_ENV/pip.conf
• per-user: ~/.config/pip/pip.conf
• legacy per-user: ~/.pip/pip.conf
• site-wide: /etc/pip.conf
• alternative site-wide: /etc/xdg/pip/pip.conf

gem (source)

• ~/.gemrc
• /etc/gemrc

cargo (source)

• $PWD/.cargo/config
• $PWD/../.cargo/config
• $PWD/../../.cargo/config
• and so on until: /.cargo/config
• $HOME/.cargo/config

(this seems too clever for its own good...)

current Bazel

(I'm not sure about order of precedence here)

• EITHER specified with --bazelrc (only the first use, repeated uses are silently ignored)
• OR $WORKSPACE/.bazelrc
• OR ~/.bazelrc
• and all of:
• $WORKSPACE/tools/bazel.rc
• bazel.bazelrc next to the binary
• /etc/bazel.bazelrc

Bazel: Klaus' proposal

• (presumably --bazelrc, but it wasn't mentioned)
• per-user-per-project-per-clone: $WORKSPACE/.bazelrc (this concept is non-standard)
• per-project: $WORKSPACE/tools/bazel.rc
• per-user: $WORKSPACE/.bazelrc
• per-machine-type: bazel.bazelrc next to the binary (this concept is non-standard)
• global: $WORKSPACE/.bazelrc

[cvcal]

Thanks for the investigation! It's a complex world out there...
When you say Workspace in the context of Bazel, I assume you mean https://docs.bazel.build/versions/master/build-ref.html#workspace, but I'm unsure what it means in the context of gradle. I'll assume similar. The cargo solution seems excessive, and I dislike relying on the working directory for settings like this, so I’m ignoring that one :)

My understanding of Klaus's proposal, which might very well be tainted with my own opinions, so might not mirror the document exactly, is closer to the following:

• per-user: $HOME/.bazelrc
  
  
  
  • what currently is loaded when --bazelrc isn't provided, I think Klaus's intended suggestion is that this file be loaded independently of the --bazelrc flag.
  
  
  • In Blaze, we have this replace-if-present logic because we intend there to only be 2 rc files, master and user, and the user can specify a specific file if the default one isn't acceptable. Unfortunately, in the bazel-land of more than 2 rc files, this replacement logic seems more confusing than helpful.
  
  
• per-machine-type: bazel.bazelrc next to the binary
  
  
  
  • This is how blaze finds its master rc, and is largely inherited from that. It can be useful when there are different binaries, we benefit from the versioning this gives us internally, but I’m not sure how useful this is externally.
  
  
• per-user-per-project-per-clone: $WORKSPACE/.bazelrc
  
  
  
  • I'm unclear on how this is better than having separate user and project rc files. Config flags allow for some fanciness there if absolutely necessary, and I think having this and the tools/ one is confusing
  
  
• per-project: $WORKSPACE/tools/.bazelrc
  
  
  
  • You are suggesting replacing this "tools" directory with "bazel" yes? Or is there something different?
  
  
• global: /etc/bazel.bazelrc.
  
  
  
  • This is similar to gem and pip’s site_wide configuration files, which is good.
  
  

[cvcal]

@aehlig, since we're talking about your design doc :smile:

[drigz]

per-project: $WORKSPACE/tools/.bazelrc
You are suggesting replacing this "tools" directory with "bazel" yes? Or is there something different?

Yep. Having seen that we currently have .bazelrc, bazel.rc and bazel.bazelrc, I'd propose using bazel/bazel.bazelrc - although that is very many bazels, and this is very much bikeshedding. I'd be fine with $WORKSPACE/.bazelrc or $WORKSPACE/bazel.rc.

per-user-per-project-per-clone: $WORKSPACE/.bazelrc
I'm unclear on how this is better than having separate user and project rc files.

We have found it useful for using --action_env to set user-specific config (eg name of dev cluster) that you wouldn't want to affect the action_env of every other project you use. However, this use case would be equally well served by using import in $WORKSPACE/tools/bazel.rc.

[cvcal]

Yep. Having seen that we currently have .bazelrc, bazel.rc and bazel.bazelrc, I'd propose using bazel/bazel.bazelrc - although that is very many bazels, and this is very much bikeshedding. I'd be fine with $WORKSPACE/.bazelrc or $WORKSPACE/bazel.rc.

bazel.rc is the release candidate, it's a binary (or at least, it is internally, I'm pretty sure for Bazel too). I agree the naming's a mess :) but I think this particular thing isn't going to change.

For config files, I think the file extension should be enough, .bazelrc is as descriptive as bazel.bazelrc, but I think the full filename is only checked in the next-to-binary case, and that's largely due to the way we do things internally, so no opinion there.

Also agreed on the bikeshedding, though if we're going to make a change in this realm, file & directory naming is a big part of that, so some amount of care is justified.

We have found it useful for using --action_env to set user-specific config (eg name of dev cluster) that you wouldn't want to affect the action_env of every other project you use. However, this use case would be equally well served by using import in $WORKSPACE/tools/bazel.rc.

Above you say you'd be fine with $WORKSPACE/.bazelrc instead of using the intermediate directory "bazel" or "tools", is this a contradiction of that?
Regardless, in terms of specificity, all WORKSPACE-relative paths are equivalent, bazel/ tools/ or otherwise. Is that wrong?

More specific rc files can easily have imports to common files that are shared between projects/users/clones, whichever. It's the other direction that's hard, so I'd rather err on the side of making these locations too specific, within reason.

[cvcal]

I think this is the list we're working from:

• user-specified: --bazelrc (making this not remove the user-home rc)
• per-user: $HOME/.bazelrc
• bazel-team provided, per installation setup: bazel.bazelrc next to the binary (might be unnecessary?)
• per-workspace: $WORKSPACE/.bazelrc (maybe with a tools/ or bazel/ intermediate directory)
• global: /etc/bazel.bazelrc.

We could then have different trigger flags for these. imperfectly, --[no]home_bazelrc --[no]binary_bazelrc --[no]workspace_bazelrc --[no]global_bazelrc. This might be too much though, trimming this down if one or more of these is in clear excess would be good. Do the binary rc and the global rc serve different cases?

For an example of the type of configuration that's possible with the above without necessarily needing a file that configures for the intersection of user and project. The user's directory can easily have --config triggered options that the user then uses in accordance with a specific project:
$HOME/.bazelrc, user-specific>

build:project_x --action_env=projectXDevCluster
build:project_x --something_else

$WORKSPACE/.bazelrc, probably shared and version controlled>

# optional, we could also expect devs testing in an environment to type out this config on the command line
build --config=project_x 

[cvcal]

@sergiocampama brings up the ordering problem, since more specific options should override competing options from a more general source. The three "master" rcs above, binary, workspace and global, don't have an obvious ranking. Maybe global < binary < workspace, but there are some cases where that wouldn't work.

[sergiocampama]

IMO the next-to-binary rc should be provided by the bazel team in the distinct packages for release, like homebrew (macOS), chocolatey (Windows) and apt-get (linux). Given that this is the set of options coming from the bazel developers, it should be the most general one.

/etc/bazel.bazelrc could be set by system admins for specific group of developers, so it could be regarded as a bit more specific than the binary one. Don't know what the windows version could like like for that.

The $WORKSPACE one could be set by team leads for a project, so it's more specific that the /etc/bazel.bazelrc

Developers sets their own in $HOME which is more specific.

Finally the --blazerc gets loaded since it's per invocation, the most specific one.

WDYT?

[sergiocampama]

You could also divide this into 2 groups, master (binary, /etc) and user (workspace, home), and have 2 flags to disable these --nomaster_bazelrc and --nouser_bazelrc. Or similar

[aj-michael]

Hardcoding /etc/bazel.bazelrc is unfortunate for testing reasons. We currently have no test coverage that it works, because any such test would require writing to /etc/bazel.bazelrc which is outside of the test sandbox. It would be nice if this location were configurable.

[aehlig]

To avoid having too many issues discussing related things, I wanted to make you
all aware of #4629. Apparently, not in all cases, all rc-files are read. This causes
problems if on the one hand, the project has to specify project-specific flags,
on the other hands, the layout of the user's home directory has to be specified;
see, e.g., #3516 (in particular, https://github.com/bazelbuild/bazel/issues/3516#issuecomment-364993240).
This lead to all kind of work-arounds being suggested, e.g., #2054.

--
Klaus Aehlig
Google Germany GmbH, Erika-Mann-Str. 33, 80636 Muenchen
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschaeftsfuehrer: Paul Terence Manicle, Halimah DeLaine Prado

[helenalt]

@ixdy please review cvcal's proposal and comment if that also works for Kubernetes

[ixdy]

Is the proposal that bazel reads both $WORKSPACE/.bazelrc and $HOME/.bazelrc? Because that would solve our issue.

Currently Kubernetes has a $WORKSPACE/.bazelrc checked into our repo, which has the unfortunate side effect of causing $HOME/.bazelrc to never be read. (Minor note: this is actually a symlink into a subdirectory to work well with the ownership/approval workflows we use.)

We don't have a tools/ directory, and I'd rather not create one solely for this file. (We also don't have a bazel/ directory, but creating that one bothers me less.)

[helenalt]

592

[cvcal]

At this point the list is looking like the following, in load order:

• global: /etc/bazel.bazelrc. (modifiyable at compile time for platforms that don't like /etc/), turn this off with --[no]global_bazelrc
• per-workspace: $WORKSPACE/.bazelrc, turn this off with --[no]workspace_bazelrc
• per-user: $HOME/.bazelrc, turn this off with --[no]user_bazelrc
• user-specified: --bazelrc (this is separate from the user bazelrc, no longer implicitly turns it off)

These will not affect each other, the presence of one will not affect Bazel's looking for the others.

[davido]

per-workspace: $WORKSPACE/.bazelrc, turn this off with --[no]workspace_bazelrc

What about backwards compatibility? Gerrit currently uses tools/bazel.rc and I would expect that this place remains supported, even after transition to more standard location $WORKSPACE/.bazelrc.

  $ cat tools/bazel.rc 
  build --workspace_status_command=./tools/workspace-status.sh --strategy=Closure=worker
  [...]

[ittaiz]

Does this mean that per user completely cancels out per workspace?
On Tue, 13 Mar 2018 at 17:17 David Ostrovsky [e-mail]
wrote:

per-workspace: $WORKSPACE/.bazelrc, turn this off with
--[no]workspace_bazelrc

What about backwards compatibility? Gerrit currently uses tools/bazel.rc
and I would expect that this place remains supported, even after transition
to more standard location $WORKSPACE/.bazelrc.

$ cat tools/bazel.rc
build --workspace_status_command=./tools/workspace-status.sh --strategy=Closure=worker
[...]

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/bazel/issues/4502#issuecomment-372701953,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABUIF1QI8NG9fOId1qzlaE6X2HQU-MNDks5td-L1gaJpZM4Rn6ig
.

[cvcal]

What about backwards compatibility?

We want Bazel 1.0 to have this issue resolved, so we won't maintain backwards compatibility forever. Part of the problem here is that these files are loaded in a confusing, inter-dependent way, and having "check $WORKSPACE and if that doesn't work check $WORKSPACE/tools" logic does seem to contradict that purpose. It's also pretty easy to make a WORKSPACE/.bazelrc file that contains exactly the line import %workspace%/tools/bazel.rc so you have both files during a transition period. Would you prefer having a more explicit support-both period? I'm worried that this might be even more confusing, since then turning off the support-both feature will be itself an incompatible change.

Does this mean that per user completely cancels out per workspace?

No, as I said, the presence of one of these files won't affect the others. This is one of the things we're trying to fix here, that these paths are all linked in relation to each other. Order does matter though, per-user will be loaded after per-workspace, so if a user overrides a workspace-specified option, then the user one wins, but the options from both will be loaded.

[drigz]

What about backwards compatibility?

Perhaps Bazel 0.x could keep the current behaviour, but warn if tools/bazel.rc is loaded without the presence of import %workspace%/tools/bazel.rc in %workspace%/.bazelrc?

Alternatively, Bazel 1.0 could print a warning if it finds a tools/bazel.rc but doesn't load it.

[cvcal]

Absolutely, there'll be warnings either before/after the change or both. Not sure it'll be exactly at the 1.0 mark, but it will be around one of the major (monthly) releases and will be clearly communicated.

What I want to avoid is reading both files, since that is neither the previous state nor the new state, and we don't want anyone relying on some sort of in-between compromise. I realize that isn't what you're suggesting, I just want to be explicit about avoiding it 🙂

[cvcal]

Quick update for those following this issue - all the preparatory refactoring I wanted to do is done, internally and externally, so the next step is to actually change the order of imports and break the current master/user bazelrc split. I'll be taking @drigz's suggestion to warn about old files that are no longer going to be loaded, along with a general warning about the change in order. To recap the change:

The old list was, in order:

• %workspace%/tools/bazel.rc (unless --nomaster_bazelrc)
• %binary_dir%/bazel.bazelrc (unless --nomaster_bazelrc)
• system rc, /etc/bazel.bazelrc or in %ProgramData% for Windows (unless --nomaster_bazelrc)
• the first of the following gets called the "user" bazelrc, (later options are not loaded if an earlier one is present, this is @ittaiz's complaint)
  
  
  
  1. path passed by flag --bazelrc
  
  
  2. %workspace%/.bazelrc
  
  
  3. $HOME/.bazelrc
  
  

The new list is hopefully a bit more consistent, as follows:

• system rc, /etc/bazel.bazelrc or in %ProgramData% for Windows (unless --nosystem_rc)
• workspace, %workspace%/.bazelrc (unless --noworkspace_rc)
• user, $HOME/.bazelrc(unless --nohome_rc)
• command-line provided, passed as --bazelrc or nothing if the flag is absent.

[ittaiz]

Awesome! This is an exciting improvement...
On Tue, 26 Jun 2018 at 1:20 Chloe Calvarin [e-mail] wrote:

Quick update for those following this issue - all the preparatory
refactoring I wanted to do is done, internally and externally, so the next
step is to actually change the order of imports and break the current
master/user bazelrc split. I'll be taking @drigz
https://github.com/drigz's suggestion to warn about old files that are
no longer going to be loaded, along with a general warning about the change
in order. To recap the change:

The old list was, in order:

• %workspace%/tools/bazel.rc (unless --nomaster_bazelrc)
• %binary_dir%/bazel.bazelrc (unless --nomaster_bazelrc)
• system rc, /etc/bazel.bazelrc or in %ProgramData% for Windows
  (unless --nomaster_bazelrc)
• the first of the following gets called the "user" bazelrc, (later
  options are not loaded if an earlier one is present, this is @ittaiz
  https://github.com/ittaiz's complaint)
  
  
  
  1. path passed by flag --bazelrc
  
  
  2. %workspace%/.bazelrc
  
  
  3. $HOME/.bazelrc
  
  

The new list is hopefully a bit more consistent, as follows:

• system rc, /etc/bazel.bazelrc or in %ProgramData% for Windows
  (unless --nosystem_rc)
• workspace, %workspace%/.bazelrc (unless --noworkspace_rc)
• user, $HOME/.bazelrc(unless --nohome_rc)
• command-line provided, passed as --bazelrc or nothing if the flag is
  absent.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/bazel/issues/4502#issuecomment-400114362,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABUIF-EEciwMYBODW4lnu7J16BZA93IQks5uAWI8gaJpZM4Rn6ig
.

[davido]

Thanks for the update. Can you provide a migration path and backwards compatibility for those projects (e.g.: Gerrit Code Review) that currently depend on %workspace%/tools/bazel.rc?

[drigz]

@davido We use both tools/bazel.rc and .bazelrc. My idea is to move it to %workspace%/.bazelrc and add import %workspace%/.bazelrc.user, then tell devs to mv .bazelrc .bazelrc.user before pulling that change.

An alternative would be to run echo "import %workspace%/tools/bazel.rc" >> .bazelrc when you see the warning about tools/bazel.rc not being loaded, but I'd expect people to miss the warning.

[cvcal]

I'm hoping devs won't miss the warning, but yes, adding "import %workspace%/tools/bazel.rc" in one of the other files would be the way to keep the old location.

Having both workspace/.bazelrc and workspace/tools/bazel.rc is redundant, so keeping the duality does not make much sense. Hopefully this won't be too disruptive - changing it all in 1 go should be less painful than having additional cleanup a few months down the road.

[davido]

We use both tools/bazel.rc and .bazelrc.

After installing Bazel 0.16.0, and moving tools/bazel.rc -> .bazel.rc, Gerrit is failing to build (on recent Gerrit master):

  $ bazel version
  Build label: 0.16.0
  $ bazel build //:gen_version --verbose_failures 
INFO: Analysed target //:gen_version (0 packages loaded).
INFO: Found 1 target...
ERROR: /home/davido/projects/gerrit2/BUILD:13:1: Executing genrule //:gen_version failed (Exit 1): bash failed: error executing command 
  (cd /home/davido/.cache/bazel/_bazel_davido/5c01f4f713b675540b8b424c5c647f63/execroot/gerrit && \
  exec env - \
    PATH=/bin:/usr/bin \
  /bin/bash -c 'source external/bazel_tools/tools/genrule/genrule-setup.sh; cat bazel-out/volatile-status.txt bazel-out/stable-status.txt | grep STABLE_BUILD_GERRIT_LABEL | cut -d '\'' '\'' -f 2 > bazel-out/k8-fastbuild/genfiles/version.txt')

Use --sandbox_debug to see verbose messages from the sandbox
Target //:gen_version failed to build
INFO: Elapsed time: 0.214s, Critical Path: 0.05s
INFO: 0 processes.
FAILED: Build did NOT complete successfully

[drigz]

@davido Did you rename to .bazelrc (should work) or .bazel.rc (as you wrote in the message?)

[davido]

@drigz My bad, I misspelled it. Sorry for the noise.

[cvcal]

Yes, sorry, 0.16 does not contain the renaming. I fell a bit behind on other work; I'm trying to make it a part of 0.17

[dapirian]

The original issue here also wanted to move tools/bazel, which is the only other thing which bazel requires a top level tools directly for. This would help us a lot to move it, was that addressed at all?

[drigz]

@dapirian A top-level %workspace%/.bazelrc is now required for a loaded-by-default config file inside your workspace. Additionally config files can be loaded with --bazelrc or by adding import %workspace%/additional/bazelrc to any of the files in Chloe's list. So I think the answer to your question is no, tools/bazel.rc is gone, and the special bazel/bazel.rc path I suggested will not be used. (for the record I'm OK with this)

[cvcal]

A few issues got combined here - None of the new paths are required, but yes, the three goals I ended up with were to remove the tools/bazel.rc, make naming more consistent, and remove the conditional-loading that we had with the "user bazelrc"s

[dapirian]

@drigz I was asking about tools/bazel, not tools/bazel.rc. When you run bazel you're really running a wrapper script which either runs bazel-real next to it or runs tools/bazel relative to your workspace, if it's present. We use this functionality (having tools/bazel wrapper) to have a hermetic bazel version associated with our commits, and afaik it's the last thing requiring a top level "tools" directory.

[drigz]

@dapirian Ah, thanks for clarifying, I misread your comment. I'm not aware of any changes to tools/bazel, and we don't use it. You might want to file a separate issue.

[cvcal]

Oh right! That has not been addressed here - Could we open another issue for that? This one is a little noisy at this point

[dapirian]

@drigz Okay.

One other issue with the new setup: to be dev-friendly I want to import %workspace%/.bazelrc.user at the top of .bazelrc to give people a place to put their personal configurations, and I want to gitignore .bazelrc.user. The problem is it's a hard error to import a file from .bazelrc which doesn't exist. If that error was hidden, this would be a much nicer developer experience.

[cvcal]

Yes, a feature request for this has been posted in #5765

[dapirian]

@cvcal https://github.com/bazelbuild/bazel/issues/5788

[cvcal]

Won't be making it in to 0.17, will roll forward to 0.18 once the release is cut

[ittaiz]

@cvcal shouldn't this commit with ignore_all_rc_files have come with release notes? Reason why I'm asking is because I started using it in a library I maintain and saw that older versions fail. I went to the release notes to see when it got in but couldn't find it in the change-log.

Also- the ignore_all_rc_files flag is equivalent to putting --bazelrc=/dev/null --nomaster --nohome_rc --nosystem_rc (if they are put last on the command line)? The answer will help me get the same functionality while supporting old bazel versions

[ittaiz]

@cvcal so apparently nohome_rc is also only available from 0.17.1 :(
Am I correct in assuming that the following options will give me a no RC build on bazel 11-16? ( “bazelrc=/dev/bull —nomaster”) If so I’ll just see if I can add a conditional on my code

[cvcal]

Yes, --ignore_all_rc_files will do what it says for any Bazel where it exists. There weren't any release notes because this flag was mostly intended as an internal tool - it ignores everything, regardless of the other flags, so --ignore_all_rc_files --master_bazelrc (in bazel 17 or earlier) or --ignore_all_rc_files --home_rc <etc> (in bazel 18 or later) does not read any file, last flag does not win, in this case. These semantics are intentional, but not very user-friendly; this flag was mostly intended to allow different versions of Bazel (including google's Blaze) to have a single no-rc configuration, which is useful for tests.

[ittaiz]

ended up bumping to 0.15.2 as minimal version and using ignore_all_rc_files

[cvcal]

15 is the first version with the flag? That sounds right

[ittaiz]

Thanks for confirming.
Still I think that if the flag exists in the docs it should have release
notes. My 2c
On Thu, 20 Sep 2018 at 20:16 Chloe Calvarin [e-mail]
wrote:

15 is the first version with the flag? That sounds right

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/bazel/issues/4502#issuecomment-423263399,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABUIF-4kIPLgQXXTtmGXD5fNeM7xL_soks5uc81-gaJpZM4Rn6ig
.

[ensonic]

Using `$HOME/.bazelrc' will clutter the home-dir. Shouldn't this be $HOME/.config/.bazelrc ? Is this supported? For details check out https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
$HOME/.config is the fallback fro $XDG_CONFIG_HOME. This inderection lets the user/admin decide where to have configuration files (important for backups too).

[cvcal]

This is not supported - we need a place that can make sense in different platforms and setups, and I'm not sure that .config is a standard location. If you care about backups in .config/, you should be able to create a thin bazelrc in HOME that imports the one in .config, which gets backed up, but that doesn't solve the clutter issue.

[ensonic]

He seriously, you are compliant with the basedir spec for other files. Eg the cached resource are under ~/.cache/bazel/bazel_$USER/. The standard I pointed to is a quite established solution.
If you are looking for a java-impl: https://github.com/omajid/xdg-java

[cvcal]

If it really is the standard as you say, then I don't know why it didn't come up earlier in the discussion about this change, we looked for standard config file locations earlier in this thread (see https://github.com/bazelbuild/bazel/issues/4502#issuecomment-360536786). Maybe we were wrong, but no one pointed it out, and so we stuck with the file location that a number of our users were already used to using.

I don't believe there's much appetite to change this list a second time, makes the release break a lot of people.

[perfinion]

I definitely agree with no more changes to the list at this point. Also basically everything I've seen that supports ~/.config/foorc also reads ~/.foorc. So lets get this change out the door as-is then in a later release we can revisit adding ~/.config/bazel/config to the list not removing ~/.bazelrc.

[gibfahn]

If it really is the standard as you say, then I don't know why it didn't come up earlier in the discussion about this change, we looked for standard config file locations earlier in this thread (see #4502 (comment)). Maybe we were wrong, but no one pointed it out, and so we stuck with the file location that a number of our users were already used to using.

FWIW the above tools mostly allow the user's bazel config to easily be moved to $XDG_CONFIG_HOME (~/.config) by reading an env var that can be set to point to the relevant directory.

# Cargo, mixes data and global config
export CARGO_HOME="$XDG_DATA_HOME/cargo"
# Npm allows customising
export npm_config_userconfig="$XDG_CONFIG_HOME/npm/config"
# Gradle puts the cache and config together.
export GRADLE_USER_HOME="$XDG_CACHE_HOME/gradle"

# Pip supports $XDG_CONFIG_HOME by default: ~/.config/pip/pip.conf

# maven and gem can't use the XDG spec.

Lots of other tools like git also have support for this, see the Arch Wiki Page for a list.

I don't believe there's much appetite to change this list a second time, makes the release break a lot of people.

That's reasonable, but is there a way to change this in a semver-minor fashion?

Ideally by adding a couple of options at the top of the per-user list, e.g.

• $XDG_CONFIG_HOME/bazelrc
• ~/.config/bazelrc
• ~/.bazelrc

Alternatively by keeping the current defaults but also reading an env var, allowing users to do export BAZEL_CONFIG=${XDG_CONFIG_HOME:-~/.config}/bazelrc.

Right now the best workaround I've found for this is alias bazel="bazel --bazelrc $XDG_CONFIG_HOME/bazel/bazelrc", but that doesn't always work.